[ Forward from Ben Cooksley. ]
----- Forwarded message from Ben Cooksley <bcooks...@kde.org> -----
Date: Fri, 24 Oct 2014 19:55:23 +1300
From: Ben Cooksley <bcooks...@kde.org>
To: ben.boec...@kitware.com
Cc: Bill Hoffman <bill.hoff...@kitware.com>, "cmake-developers@cmake.org"
<cmake-developers@cmake.org>
Subject: Re: [cmake-developers] Fwd: Re: Severe behavioural change
regressions in release branch
On Fri, Oct 24, 2014 at 3:34 PM, Ben Boeckel <ben.boec...@kitware.com> wrote:
> [ Adding Ben Cooksley to the CC list; feel free to reply privately and
> I'll forward to the list if you keep getting rejected from it. ]
Duly noted, will do.
>
> Hi,
Hi,
>
>> > It would appear that CMake 3.0 to 3.1 introduces a colossal change in
>> > behaviour. This change totally breaks all KDE projects which use
>> > Extra-CMake-Modules, as necessary headers are no longer installed.
>
> This is indeed true (between the new variable expansion code (CMP0053)
> and 'if()' variable expansion rules (CMP0054), there's a lot of
> changes otherwise); however, all you should get are warnings about the
> change, not the actual behavior change without actually bumping your
> minimum version or enabling the policy explicitly.
Oki, that sounds about right.
>
>> > This has become an issue following http://build.kde.org/job/cmake/160/
>> > which has led to a significant number of our projects failing to build
>> > from source as can be seen here -
>> > http://build.kde.org/view/Frameworks/
>
> So looking at kdelibs4support, I see lots of CMP0053 warnings (due to
> the @var@ expansion in normal CMakeLists.txt processing which was
> obscure and undocumented) and CMP0048 warnings (I'm not familiar with
> it, but it's about project() offering version variables). In kdelibs, I
> see CMP0022 and CMP0046 warnings (both related to target_link_libraries
> and things which are likely bugs anyways such as depending on
> non-existent targets or a mismatch between INTERFACE_LINK_LIBRARIES and
> LINK_INTERFACE_LIBRARIES).
>
> However, I do see:
>
> 04:35:39 -- Installing:
> /srv/jenkins/workspace/kdelibs_master/local-inst/srv/jenkins/install/linux/x86_64/g++/latest-qt4/kde/kdelibs/inst/include/kpluginfactory.h
>
> in kdelibs' logs, so it makes me think that:
>
>
> /srv/jenkins/workspace/kdelibs4support_master_qt5/src/kssl/kcm/kcmssl.cpp:27:28:
> fatal error: kpluginfactory.h: No such file or directory
>
> implies the build isn't getting the include directories plumbed through
> properly. I'll try a build tomorrow (or if it'd be possible to run a
> Jenkins build of kdelibs4support with make VERBOSE=1, that'd be great
> too since the environment would be consistent then). My gut feeling is
> some CMP0054 corner case isn't caught and falls through to the new
> behavior without a warning (or the old behavior was subtly changed in
> the process), but that's just a shot in the dark.
Slight bit of confusion here, sorry about that.
kdelibs_master is for the KDE 4 (Qt 4 based) series of software.
kdelibs4support_master_qt5 is for the Frameworks 5 (Qt 5 based) series
of software.
In this case, kpluginfactory.h should come from kcoreaddons.
It's build log can be found here -
http://build.kde.org/job/kcoreaddons_master_qt5/153/consoleText
I can't see a sign of kpluginfactory.h being installed there unfortunately.
Others have done a bit of digging already it seems as to what might be
the cause.
Please see
https://mail.kde.org/pipermail/kde-frameworks-devel/2014-October/019906.html
for that.
If you're still interested in a VERBOSE=1 build of some of our
projects, i'll be more than happy to supply such a log.
>
>> > Someone needs to investigate this before CMake 3.1.0 goes out the door
>> > and fix it. I've no idea what the policy is in the CMake world, but in
>> > the KDE world this sort of compatibility breakage would be a release
>> > blocker.
>
> Thanks for testing the rc; it should be a blocker on our side too. It
> would indeed be bad for 3.1.0 to release with such breaking changes.
> We try really hard for backwards compatibility. Obviously our test
> coverage is lacking somewhere.
That is a relief to know.
>
>> And it would seem that the CMake developers prefer to live in their
>> own closed off little bubble. My post was automatically rejected.
>> Someone who is subscribed there will have to take this up with them.
>> I'm extremely displeased.
>>
>> If they release CMake 3.1.0 with this regression, we should consider
>> forking CMake as their developers can't be trusted to ensure our code
>> remains buildable.
Sorry for that - I got a bit caught up in the heat of the moment.
>
> 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?
>
> Thanks,
>
> --Ben
Thanks,
Ben
----- End forwarded message -----
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
