From: Jurko GospodnetiÄ (jurko.gospodnetic_at_[hidden])
Date: 2008-09-03 17:26:56
>> Could we refactor this so that the generator selection is done only
>> after all the user Jamfiles have been processed?
>> I have not looked at the code yet so I do not have a feeling of how
>> difficult this would be but I guess that would be the most natural
>> implementation as the whole Boost Build syntax is quite declarative.
>> I.e. first we define what we want to happen, and only then does the
>> actual build process commence, not requiring any further interaction.
> What happens when a generator instiantates a target as is the case with
Would that really present a problem? I mean, we have no problem with
generators constructing additional targets, just possibly with
generators attempting to declare additional generators... and even that
could be dealt with by playing with the cache Volodya mentioned.
As I see it parts of the Boost Build build procedure related to this
would could go:
1. Parse Jamfiles and construct all the Boost Build objects
modeling data user entered.
2. Process requested targets, looking for a way to construct them
using generators in case of typed targets. In the process new targets
could possibly be constructed (I do not really understand why that would
be needed though but that's a separate issue and more than likely based
on my ignorance) and would be added to the list of unprocessed targets
getting processed in this same step.
3. Build continues as usual by actualizing all the virtual targets
collected from step 2.
Again... I have not yet looked at the code yet so I might be saying
dumb things here... :-)
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk