Boost logo

Boost-Build :

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:

   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ć

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at