[cmake-developers] [bcooksley at kde.org: Re: Fwd: Re: Severe behavioural change regressions in release branch]

[Ben Boeckel]

On Fri, Oct 24, 2014 at 10:22:49 -0400, Ben Boeckel wrote:
> > For preventing this in the future, would it be possible to set up
> > Jenkins build to submit builds for kdelibs and a few other libraries
> > which would test CMake master and submit to CMake's dashboard some
> > results nightly so we can catch these problems more quickly? There are
> > examples in:
> >
> >     https://github.com/Kitware/CMake/tree/master/Tests/Contracts
> >
> > for how this is done for other projects already. The instance would
> > then just to set something like CMAKE_CONTRACT_PROJECTS=kdelibs and run
> > CMake's test suite and submit to the dashboard.
> 
> Theoretically that is possible, although a little complicated. We
> would have to chain two or more Frameworks builds (each one relying on
> the results of the prior build) in this case in order to detect the
> regression which tripped us up here. It is something which would need
> some adjustments to how our CI scripts work, but is certainly
> feasible.
> 
> Just to be sure, such a job would:
> 
> 1) Build the latest CMake (branch next)
> 2) Use the newly built CMake to compile all of the Frameworks, run
> their unit tests and submit each one to CDash.
> 3) Execute the CMake unit tests and submit this to CDash as well.
> 
> For each submission to CDash, would the same CMAKE_CONTRACT_PROJECTS
> variable apply? ie. they would all be kde-frameworks or similar, even
> though we're making multiple submissions?

So the way it works is that the contract build actually happens during
CMake's ctest run. So to do this, you could add two libraries which
depend on each other into the contract test. Basically all that needs to
be done is to set up externalproject_add calls for the two with proper
dependencies between them.

There shouldn't be a need for building cmake then chaining it out to
some other build instance.

--Ben