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
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.
> > Is this a bug on Boost.Build?
Well, I consider this a feature :-)
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.
-- * 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
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