Subject: Re: [Boost-build] Another funny Boost Build behaviour. [PATCH]
From: Jurko GospodnetiÄ (jurko.gospodnetic_at_[hidden])
Date: 2008-09-04 20:33:36
>> 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
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.
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