Should parrot_config report separate inst_ and build variables?

[doughera]

Some discussion of this topic is on the parrot-dev mailling list, starting at:  http://lists.parrot.org/pipermail/parrot-dev/2009-April/002158.html (The thread continues into the beginning of the next month, here at  http://lists.parrot.org/pipermail/parrot-dev/2009-May/002162.html and  http://lists.parrot.org/pipermail/parrot-dev/2009-May/002172.html.)

I have tentatively assigned this ticket a milestone of 1.4, the next "supported" release. If indeed version 1.4 is to be packaged and widely distributed, then it would be nice to clear up such issues beforehand.

[doughera]

One way I was imagining this might be implemented is to indeed have Configure.pl generate two versions of each of the relevant variables, e.g. libparrot_linkflags and inst_libparrot_linkflags , to pick an example from TT #698. In the build directory, parrot_config would contain both of these, but the normal usage, namely libparrot_linkflags would pick up the build directory version. Upon building the parrot_config for installation, however, every inst_* variable would be copied to it's corresponding non-inst_ variable (e.g. inst_libparrot_linkflags would be copied to libparrot_linkflags) so that in the installed version, you would also simply use libparrot_linkflags. That is, users of parrot's config information would use the same interface regardless.

The change would also be rather mechanical -- each inst_ variable has a corresponding version without the inst_ prefix. The inst_ variables could all be set up in Configure.pl right after the plain versions were set. Unfortunately, the installed vs. not-installed information is currently spread out in diverse ways across many files. Various build tools have --install flags that do various things. Ideally, in the end, all they would do is pick out which parrot_config file to load in, and much of the remaining conditional code could be eliminated.

At least that's how I've been thinking it might look going forward.

[doughera]

A few other loosely-related tickets are: TT #476, TT #495, TT #540, TT #691, TT #735, TT #739, and TT #762. All of these rely on basic config information.

[wayland]

Anyone looking at this should be aware of  http://lists.parrot.org/pipermail/parrot-dev/2009-July/002482.html

[doughera]

Replying to whiteknight: I think this ship has sailed. It might be more fruitful to close this ticket and open a new one that more specifically addresses the issue from the point of view of a language developer or an embedder/extender.