What's the point of yaml-cpp-targets?

[tambry]

Currently I have yaml-cpp as a git submodule, that gets added using add_subdirectory to my own project. Calling find_package(yaml-cpp) on CMake 3.7 generates the following error:

The file

   .../build/3rdparty/yaml-cpp/yaml-cpp-targets.cmake

  was generated by the export() command.  It may not be used as the argument
  to the include() command.  Use ALIAS targets instead to refer to targets by
  alternative names.

After going through the yaml-cpp CMakeLists.txt I'm not quite sure why this file is needed to be generated. Generating this file through the export command generates the error shown above when being built inside another project (ie. as a submodule).
Note that there's also a SO question here, that has an answer that is not ideal at all for my usage - I want to include it as a submodule and then build it.

Is this really needed? Is there any way I can workaround this problem, besides simply disabling the generation of that file?

[tambry]

I might also might note that disabling the include directive here will fix the problem and seems to cause no other issues.

[jbeder]

I don't know; I just accepted a patch request. I don't use find_package, so I just depended on others to make sure it works.

If you can figure out why it's there and update it (ideally rather than simply disabling it), that'd be awesome!

[tambry]

After reading the CMake wiki page on exporting/importing, I'm still quite confused as to why it's there. CMake wiki brings one example of it allowing compiling the project for running on the host machine (ie. special generator or something), that can be run then and then the rest of the project can be cross-compiled from something else, from what I understand.

Would you be fine with adding an option to disable that include? (keeping the current behaviour by default, but allowing to turn it off)

[jbeder]

@paulnovo I think you authored the original change a397ad2. What do you think?

[sergiud]

The point of yaml-cpp-targets.cmake is that it creates an imported target yaml-cpp which ideally would allow to easily link to yaml-cpp using target_link_libraries (and no additional commands) after a find_package call. However, the export mechanism as currently implemented by yaml-cpp is not relocatable (as every path is kept absolute) making the yaml-cpp-config.cmake practically unusable.

@tambry The line should not be removed. Please look up in the CMake documentation on how to correctly create CMake packages. The CMakePackageConfigHelpers module required for this is available since CMake 2.8.8.

[sergiud]

I can provide a fix for this config mess unless someone is already working on this.

[tambry]

@sergiud I don't think anyone is working on this yet. At least I'm not and don't see anyone else on the network graph that is.

Linking part is good except if I need to find the include directory. Sure, I got my own project, it will know the directory, but if I have another smaller project as a submodule that also uses yaml-cpp, then it's hard to know the exact include directory. Calling find_package(yaml-cpp) in such a situation would be the solution, but currently that's impossible due to the slight mess.

[sergiud]

@tambry I see that you actually include yaml-cpp using add_subdirectory in addition to calling find_package (yaml-cpp). This is incorrect. Either you call add_subdirectory and link to the yaml-cpp target directly, or you use the ExternalProject CMake module in combination with find_package. The latter being the recommended method.

[sergiud]

@tambry Please test #446.

[paulnovo]

Yes, @tambry, you need to use ExternalProject_Add. This should currently work fine, I use yaml-cpp this way. If that works for you, I think we can close this issue, and consider #446 separately.

@sergiud I wouldn't consider the current packaging a mess, it was the recommended way to do this when I implemented this code, admittedly a long time ago, and it works with old (getting very old) versions of CMake.

[sergiud]

@paulnovo Sorry for the wording. The reason for calling the current package config a mess is that yaml-cpp-config.cmake in most distributions that package yaml-cpp is broken. Specifically, the yaml-cpp imported target often points to non-existent shared objects as the packages are built in a directory different from the install location. Take #362 for example. This is still the case on update-to-date Arch Linux.

[paulnovo]

@sergiud I can have a look at what Arch is doing, but Debian (which I packaged) uses this without problems. Just to clarify, currently, yaml-cpp creates two yaml-cpp-config.cmake files. One for the Build directory, with correct paths to the build directory. And one that is installed, with correct paths to the install directories.

BTW, #362 seems to be fixed by me in #344, with the code we are discussing here.

[sergiud]

@paulnovo The issue is still present in Arch. Building targets that use yaml-cpp-config.cmake fail with the error message from #362.

[paulnovo]

@sergiud I don't know much about Arch packaging, but I am looking at the PKGBUILD file. It looks like line 27 runs make install, which should install the correct yaml-cpp-config.cmake, yaml-cpp-config-version.cmake, and yaml-cpp-targets.cmake. Lines 29-31 appear to overwrite these files with the ones from the Build directory. Is there a way you could test removing lines 29-31?

[sergiud]

@paulnovo The problem is not in yaml-cpp-config.cmake, but in yaml-cpp-targets.cmake. The yaml-cpp target here points to the /build/yaml-cpp/src/yaml-cpp-release-0.5.3/libyaml-cpp.so.0.5.3 shared object which does not exist on the host system. The path seems to be used by the Arch build farm. This is with yaml-cpp installed using the package manager. I do not compile yaml-cpp myself.

Edit: Missed the install lines in PKGBUILD. These seem to cause the problem. Thanks for looking into this!