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ć