[CMake] Relation Between CMP0074 and Installed Config Files

Stephen McDowell sjm324 at cornell.edu
Wed Sep 12 11:17:17 EDT 2018


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!

[1]: https://cmake.org/cmake/help/latest/policy/CMP0074.html

[2]: https://github.com/PointCloudLibrary/pcl/blob/master/PCLConfig.cmake.in

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 ;)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180912/abbc3e20/attachment-0001.html>


More information about the CMake mailing list