Should parrot_config report separate inst_ and build variables?

[Allison Randal]

Andy Dougherty 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?

Keep in mind that the build version of parrot_config needs to have 
access to both the installed and the build directory versions of those 
config variables. It has to be able to copy files from build location to 
the install location, and to compile and link both installable_* and 
regular versions of the executables.

The build versions of the config variables can be dropped from the 
installed parrot_config. It's more complicated than just parrot_config, 
though, because a number of the Perl tools access the same information 
from a Perl hash stored in lib/Parrot/Config/Generated.pm, which is used 
by both build and installed tools.

Allison