<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Hello,</div><div><br></div><div>I am on the task force for modernizing the CMake build system of a large project, the Point Cloud Library (PCL).  Satisfying policy <span style="font-family:monospace,monospace">CMP0074</span> [1] has us somewhat confused about what we should be doing.</div><div><br></div><div>At <i>build time</i>, we understand.  Our numerous <span style="font-family:monospace,monospace">FindStuff.cmake</span> 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 <span style="font-family:monospace,monospace">${Package_ROOT}</span> and <span style="font-family:monospace,monospace">$ENV{Package_ROOT}</span> in the search paths.  This makes sense and is relatively straightforward to check for each of our Find modules.</div><div><br></div><div>Where we are confused is about <span style="font-family:monospace,monospace">PCLConfig.cmake</span> [2].  Ignoring the fact that the file needs some love in general, the current scheme needs modification to fully satisfy <span style="font-family:monospace,monospace">CMP0074</span>.  Choosing an arbitrary example, here is what is done for qhull</div><div><br></div><div><span style="font-family:monospace,monospace">    macro(find_qhull)<br>      if(PCL_ALL_IN_ONE_INSTALLER)<br>        set(QHULL_ROOT "${PCL_ROOT}/3rdParty/Qhull")<br>      elseif(NOT QHULL_ROOT)<br>        get_filename_component(QHULL_ROOT "@QHULL_INCLUDE_DIRS@" PATH)<br>      endif(PCL_ALL_IN_ONE_INSTALLER)<br><br>      set(QHULL_USE_STATIC @QHULL_USE_STATIC@)<br>      find_package(Qhull)<br>    endmacro(find_qhull)</span></div><div><br></div><div>When considering the usage of this in a consuming project that issues a <span style="font-family:monospace,monospace">find_package(PCL X.Y.Z REQUIRED)</span>, 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 <span style="font-family:monospace,monospace">-DQHULL_ROOT=/some/path</span>.  In other words, the scheme here was created to make sure that the same dependencies that were found when <i>compiling</i> PCL are found when <i>using</i> PCL.</div><div><br></div><div>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</div><div><br></div><div>> basically provide the necessary find modules themselves, but don't cache the results of your find calls when installing.<br></div><div><br></div><div>AKA instead of renaming these variables e.g. <span style="font-family:monospace,monospace">QHULL_ROOT</span> -> <span style="font-family:monospace,monospace">PCL_QHULL_ROOT</span> to satisfy <span style="font-family:monospace,monospace">CMP0074</span>, 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.</div><div><br></div><div>(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?</div><div>(b) Even if we create proper imported interface libraries to do <span style="font-family:monospace,monospace">target_link_libraries(pcl PUBLIC qhull::qhull)</span>, this will not help us in terms of installation -- the find modules still need to be installed / called in <span style="font-family:monospace,monospace">PCLConfig.cmake</span>, right?</div><div>(c) Since we need to more carefully analyze our project with respect to <span style="font-family:monospace,monospace">CMP0074</span>, is it advisable to set it to <span style="font-family:monospace,monospace">OLD</span> 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 <span style="font-family:monospace,monospace">OLD</span> (rather than just <i>not</i> setting it to <span style="font-family:monospace,monospace">NEW</span>) is the correct approach <b>for this release only</b>.<br></div><div><br></div><div>Thank you for any insights!<br></div><div><br></div><div>[1]: <a href="https://cmake.org/cmake/help/latest/policy/CMP0074.html">https://cmake.org/cmake/help/latest/policy/CMP0074.html</a></div><div><br></div><div>[2]: <a href="https://github.com/PointCloudLibrary/pcl/blob/master/PCLConfig.cmake.in">https://github.com/PointCloudLibrary/pcl/blob/master/PCLConfig.cmake.in</a></div><div><br></div><div>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 ;)<br></div></div></div></div></div>