Relation Between CMP0074 and Installed Config Files

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Relation Between CMP0074 and Installed Config Files

Stephen McDowell
Hello,

I am on the task force for modernizing the CMake build system of a large project, the Point Cloud Library (PCL).  Satisfying policy CMP0074 [1] has us somewhat confused about what we should be doing.

At build time, we understand.  Our numerous FindStuff.cmake modules (some of which we will be removing, e.g., Eigen, some we cannot, e.g., libusb-1.0) should be checked and verified that when finding paths / libraries, we need to verify that we also check both ${Package_ROOT} and $ENV{Package_ROOT} in the search paths.  This makes sense and is relatively straightforward to check for each of our Find modules.

Where we are confused is about PCLConfig.cmake [2].  Ignoring the fact that the file needs some love in general, the current scheme needs modification to fully satisfy CMP0074.  Choosing an arbitrary example, here is what is done for qhull

    macro(find_qhull)
      if(PCL_ALL_IN_ONE_INSTALLER)
        set(QHULL_ROOT "${PCL_ROOT}/3rdParty/Qhull")
      elseif(NOT QHULL_ROOT)
        get_filename_component(QHULL_ROOT "@QHULL_INCLUDE_DIRS@" PATH)
      endif(PCL_ALL_IN_ONE_INSTALLER)

      set(QHULL_USE_STATIC @QHULL_USE_STATIC@)
      find_package(Qhull)
    endmacro(find_qhull)

When considering the usage of this in a consuming project that issues a find_package(PCL X.Y.Z REQUIRED), the motivation behind this approach was to help facilitate that the library path that was used when PCL was built will be recovered, unless the consuming project defines / is configured with -DQHULL_ROOT=/some/path.  In other words, the scheme here was created to make sure that the same dependencies that were found when compiling PCL are found when using PCL.

I asked about this on the cpplang slack, and one of the cmake devs (whose word I generally follow blindly without question xD) told me this

> basically provide the necessary find modules themselves, but don't cache the results of your find calls when installing.

AKA instead of renaming these variables e.g. QHULL_ROOT -> PCL_QHULL_ROOT to satisfy CMP0074, we should delete them.  The conversation was brief and I did not include much context, but I am wondering if people here could share their thoughts on this.

(a) Why is providing measures to make sure the same libraries used at compilation of PCL are the same ones found when using PCL bad?
(b) Even if we create proper imported interface libraries to do target_link_libraries(pcl PUBLIC qhull::qhull), this will not help us in terms of installation -- the find modules still need to be installed / called in PCLConfig.cmake, right?
(c) Since we need to more carefully analyze our project with respect to CMP0074, is it advisable to set it to OLD for the imminent release?  The release will go out before we have time to properly update our CMake code for this policy, and we want to make sure that setting it to OLD (rather than just not setting it to NEW) is the correct approach for this release only.

Thank you for any insights!



P.S. To the original advisor who told me not to cache the results, I apologize in advance for having the audacity to doubt your infinite CMake wisdom.  I don't understand why caching the results for installation is bad / what can go wrong by this, and would like to ;)

--

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:
https://cmake.org/mailman/listinfo/cmake