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

Subject: Re: [Boost-build] [Boost-testing] Incremental build and changes on Jamfiles only
From: Jürgen Hunold (jhunold_at_[hidden])
Date: 2013-01-12 10:17:24

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.

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.

Hope this helps.

Yours,

Jürgen
-- 
* Dipl.-Math. Jürgen Hunold  ! 
* voice: ++49 4257 300       ! Fährstraße 1
* fax  : ++49 4257 300       ! 31609 Balge/Sebbenhausen
* jhunold_at_gmx.eu             ! Germany