Should parrot_config report separate inst_ and build variables?

Will Coleda will at coleda.com
Tue May 5 02:45:48 UTC 2009


On Mon, May 4, 2009 at 10:06 PM, Allison Randal <allison at parrot.org> wrote:
> 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
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev
>

Then we can have "inst_foo" which is always the installed version, and
'foo', which depends on the current location.

If the perl hash needs to be updated similarly, so be it. (Or, it can
just invoke parrot_config to get the desired values if necessary)

-- 
Will "Coke" Coleda


More information about the parrot-dev mailing list