Should parrot_config report separate inst_ and build variables?

[Will Coleda]

On Thu, Apr 30, 2009 at 12:21 PM, Andy Dougherty <doughera at lafayette.edu> wrote:
> Some config variables have two variants, e.g. ldflags_libparrot and
> inst_ldflags_libparrot, intended for use either in the build directory or
> install directory.  Hence a language needs to decide which variant to use,
> depending on whether or not it's building against an installed parrot.
>
> Is that the desired behavior?  Or, perhaps, should the installed version
> of parrot_config *know* that it's the installed version and simply report
> the inst_ version of variables?
>
> On a related note, it might be nice to try to regularize the variable
> names somewhat.  I tend to think the name used by the installed version
> ought to be the simpler, more obvious one; the build directory can use a
> longer, clunkier name.
>
> --
>    Andy Dougherty              doughera at lafayette.edu
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev
>

IMO, all the config keys should NOT have an install vs. a build
variant. This way a language can just call "parrot_config", and be
sure they're getting the right values. If we need to check the
installable version, we can use the installable variant of
parrot_config in the build dir. We should never need to know the build
dirs used in the installed version.

I'm facing this issue with partcl now; I decided to build against an
installed parrot, but that makes reconfiguring against an svn-checkout
of parrot very painful.

-- 
Will "Coke" Coleda