[cmake-developers] Fwd: Re: Severe behavioural change regressions in release branch

[Ben Boeckel]

[ 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. ]

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.

> > 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.

> > 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.

> 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.

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.

Thanks,

--Ben