Re: [Boost-testing] Incremental build and changes on Jamfiles only

Subject: Re: [Boost-testing] Incremental build and changes on Jamfiles only
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2013-01-13 14:41:35

Le 12/01/13 16:17, Jürgen Hunold a écrit :
> Hi Vicente,
>
> On Saturday, 12. January 2013 13:13:02 Vicente J. Botet Escriba wrote:
>> Le 06/01/13 11:39, Vicente J. Botet Escriba a écrit :
>>> Hi,
>>>
>>> I was wondering how the regression testers using an incremental build
>>> behave when there is just a change on the Jamfile.
>>> Would the targets for which the action that built them has changed be
>>> rebuilt?
> No. The usual way is to ask the incremental testers to clean their builds via
> the "testing" mailing list.
>
>>> I'm asking this because in my computer I need to pass the -a option to
>>> ensure that everything is coherent.
> Yes.
>
>>> Is this a bug on Boost.Build?
> Well, I consider this a feature :-)
>
> Rationale:
> In order to detect changed compiler flags, defines et.al. one have cache those
> settings somewhere. Meta-build systems like CMake already do this, but
> Boost.Build does (not yet) have a caching system, as well as plain old make.
>
> In my experience cache based system can have other, more serious issue when
> the cached data gets dirty without getting noticed.
>
> There is a thin line between "bug" and "feature" here.
Agreed.
> One other possibility is to combine flags changes with some (cosmetical) header
> change (config.hpp of your library) in order to trigger a full rebuild.
>
>>> If yes, shouldn't incremental build be avoided on regression testers?
> Theoretically, yes. But as full builds tend to run very long on certain
> platforms, this might reduce the testing frequency a lot. And "basic" settings
> like defines and flags don't change as often as implementation code.
>
>
Agreed again.

One alternative: Couldn't Boost.Build warn the user when one of the 
Jamfiles have been changed if an incremental build is done?

Best,
Vicente