Re: [Boost-build] Another funny Boost Build behaviour.

From: Jurko Gospodnetić (jurko.gospodnetic_at_[hidden])
Date: 2008-09-03 17:26:56

   Hi Steven.

>>   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 
> quickbook.

   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... :-)

   Best regards,
     Jurko Gospodnetić