Ticket #649 (new RFC)

Opened 5 years ago

Last modified 4 years ago

Should parrot_config report separate inst_ and build variables?

Reported by: doughera Owned by: whiteknight
Priority: normal Milestone:
Component: install Version: 1.1.0
Severity: medium Keywords:
Cc: Language:
Patch status: Platform:

Description

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.

Change History

  Changed 5 years ago by 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.

  Changed 5 years ago by 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.

  Changed 5 years ago by wayland

  Changed 5 years ago by coke

  • milestone 1.4 deleted

follow-up: ↓ 6   Changed 4 years ago by whiteknight

  • owner set to whiteknight

in reply to: ↑ 5   Changed 4 years ago by 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.

Note: See TracTickets for help on using tickets.