cmake 2.6 no longer supported

[blinkseb]

Hi,

We are using yaml-cpp in a lot of projects on various remote UI (mainly at CERN) which are all running on Scientific Linux 6 (a derivative of RedHat 6), unfortunately stuck with cmake 2.6.

When trying to build yaml-cpp on such a machine, there's a cmake error:

CMake Error at CMakeLists.txt:311 (export):
  export Unknown arguments.

The error appears when we upgraded to yaml-cpp 0.5.3 and was not present on 0.5.1. I've tracked the issue to a397ad29252b60f0549a4edb389a46a37577cd02 and indeed, export(PACKAGE does not seem to be supported in cmake 2.6.

Woud it be possible to restore cmake 2.6 compatibility? If not, at least set the min. cmake version to 2.8 for an explicit error message.

Thanks a lot for such great lib!

Cheers, Sébastien

[jbeder]

Do you have a solution to preserve cmake 2.6 compatibility? I'm happy to accept a patch but I don't know an alternative for export(PACKAGE). (To be honest, that line was in a pull request I received, so I didn't author it myself.)

If not, I suppose I can just up the min cmake version.

[winterheart]

This feature available since CMake 2.8. Only solution I can see is using EPEL repository which provides cmake 2.8.x package.

[ishitatsuyuki]

Come on, this is 2016, not 2008, you think 2008 compilers can really handle c++11?

[tamaskenez]

It would be very easy to optionally skip export(PACKAGE ...) with an if(NOT CMAKE_VERSION VERSION_LESS 2.8) so it would still work with 2.6 and while not losing the export feature.

On the other hand I strongly discourage using export(PACKAGE ...) in the first place. It tends to create very obscure bugs (experience). And it's not even necessary since install(EXPORT ...) works fine.

[sergiud]

@tamaskenez You should at least mention the bugs you are talking about. Otherwise it's just spreading of FUD. Also, in my experience, the export command works very well.

[tamaskenez]

@sergiud

In my experience: when, due to some misconfiguration, the find_package for a package failed to locate the config-module, it did find an entry in the package-registry which referred to an incorrect or incorrectly configured build tree.

So instead of a simple "config-module not found" error I got linker or runtime problems later. Because of the lack of the error message I assumed my intended config-module and installation was in effect. That's why it was hard to debug.

export(PACKAGE) introduces a third, hidden thing that could happen when you issue a find_package command.

[sergiud]

@tamaskenez I see. This is, however, a problem with the config module itself and not a limitation of CMake's export mechanism (especially if no imported targets but CMake 2.6 style cache variables, i.e., <LIBRARY>_INCLUDE_DIRetc., are provided).

CMake 2.8.x introduced the CMakePackageConfigHelpers module which greatly simplifies generation of build tree and install time config. For instance, glog recently added support for CMake which required just adding a couple of lines of code to the CMakeLists.txt to generate the config, and works flawlessly when exporting the local build tree without requiring additional logic.

[tamaskenez]

@sergiud

(It was not a problem with the config-module, only a bad CMAKE_PREFIX_PATH).

My fundamental problem with export(PACKAGE) is that it introduces a third thing that can happen in the find_package command. And it's a behind-the-scenes thing, as opposed to something explicitly written out in command parameters.

May I ask, what is the thing about your workflow that makes you prefer using the package-registry instead of installing the dependency and finding its config-module?

, the config-module itself was fine(

[sergiud]

@tamaskenez This may happen if you compile several versions of the library (possibly using different compilers with incompatible ABIs) and only the latest build is registered in the package registry. But this is again not a problem exclusively related to CMake's export.

I prefer the package registry because I do not have to install the package everytime I recompile the library after an update. Also on Windows where no standard directory layout exists as opposed to Unix, I don't have to explicitly specify the location of every dependency as it will be discovered automatically.

In my experience, it is not relevant what happens behind the scenes in a CMake config. It is package's responsibility to determine all the parameters and dependencies instead of imposing this burden upon the user. With imported targets (since CMake 2.6) this has become even easier and eliminates the need of defining legacy style <LIBRARY>_INCLUDE_DIR variables in configs.

[tamaskenez]

In our workflow the user has to provide a single CMAKE_PREFIX_PATH for a given workspace and all dependencies will be installed or looked up there (works on Windows, too, without any changes). Also, an inhouse build tool automatically rebuilds and installs updated packages and their dependent projects on request.

Anyway, I see your point, too. Using directly the build tree of a dependency certainly has the advantage that you don't start editing a dependency's installed header by mistake because the IDE pops it up in the main project.

[sergiud]

I see. However, specifying CMAKE_PREFIX_PATH does not interfere with export at all. In fact, CMake looks for packages in CMAKE_PREFIX_PATH first and then in the user package registry (see the numbered list at the bottom of the page https://cmake.org/cmake/help/v3.6/command/find_package.html?highlight=find_package). Not a problem here as well.

[jlquinn]

CentOS 6 has cmake 2.8.12. Is SciLinux 6 still stuck on cmake 2.6?