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

Subject: Re: [Boost-build] Another funny Boost Build behaviour. [PATCH]
From: Jurko Gospodnetić (jurko.gospodnetic_at_[hidden])
Date: 2008-09-04 20:33:36

   Hi.

>>    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.
> 
> That would be fairly hard. Presently, we try not to load all and every Jamfile. That is,
> if you have:
> 
> 	exe a : a.cpp some_dir//some_target ;
> 
> then some_dir/Jamfile will be only read if 'a' is actually built. And if that Jamfile has
> 'import xxx' then some generators maybe be declared, or not declared, depending on
> whether 'a' is built, and on when exactly 'a' is built.
> 
> I think converting this into two-pass process when we first figure which targets are
> built and load Jamfiles, and then build targets, might be troublesome. Really,
> just cleaning the cache might be enough :-)

   Ok. I've committed a patch for this that clears the cached values 
when registering a new generator. A related test case has been added to 
the Boost Build test suite.

   Changeset link: http://svn.boost.org/trac/boost/changeset/48590

   I guess we'll leave the fine tuning and refactoring the whole Jamfile 
processing for the future :-), most likely for after we move on to the 
Python implementation.

   After looking at the sources I have a hunch there still exists a 
similar bug with defining a new derived target type, but I'll get back 
to you on that when I get a change to test it out.

   Best regards,
     Jurko Gospodnetić