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

[Ben Boeckel]

----- Forwarded message from Ben Cooksley <bcooksley at kde.org> -----

Date: Sun, 26 Oct 2014 11:50:45 +1300
From: Ben Cooksley <bcooksley at kde.org>
To: Ben Boeckel <ben.boeckel at kitware.com>
Subject: Re: [bcooksley at kde.org: Re: [cmake-developers] Fwd: Re: Severe
	behavioural change regressions in release branch]

On Sun, Oct 26, 2014 at 3:02 AM, Ben Boeckel <ben.boeckel at kitware.com> wrote:
> 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.

Okay, that sort of simplifies things a bit. I'll need to look into
this further and probably talk with someone who is more familiar with
CMake than I am to help to get it sorted out, but it should be
possible to get this arranged with our setup.

(The list still has me blocked, so this will need to be forwarded as well)

>
> --Ben

Thanks,
Ben

----- End forwarded message -----