3 ms·

Is there a good introduction to CMake for those of us on the receiving end, i.e., we’re trying to build a package, maintained by someone else, which uses CMake?

• SAI_Peregrinus 3y ago
  Cmake's built-in find_package[1] often[2] just ends up using pkg-config[3] under the hood. There are a bunch of environment variables you can set to add more search paths, either to pkg-config or to CMake Find scripts. If a library isn't packaged for CMake or pkg-config, you can write a CMake package and add it to your user package registry[4]. This is, of course, a massive pain in the ass, but C & C++ library packaging is about twelve different kinds of massive pain in the ass, and CMake is easier to write than a lot of the other packaging formats, so this is a small part of it. [1] https://cmake.org/cmake/help/latest/command/find_package.html https://cmake.org/cmake/help/latest/command/find_package.htm... [2] https://cmake.org/cmake/help/latest/module/FindPkgConfig.html#module:FindPkgConfig https://cmake.org/cmake/help/latest/module/FindPkgConfig.htm... [3] https://www.freedesktop.org/wiki/Software/pkg-config/ https://www.freedesktop.org/wiki/Software/pkg-config/ [4] https://cmake.org/cmake/help/latest/manual/cmake-packages.7.html https://cmake.org/cmake/help/latest/manual/cmake-packages.7....
  • helloiamsomeone 3y ago
    > find_package often just ends up using pkg-config find_package() is just a souped-up include(). What happens once it finds the script matching the criteria provided by arguments and cache variables depends entirely on the script(s) (plural, because version criterion is satisfied by the *ConfigVersion.cmake script for config mode search) it runs. The PkgConfig module is only mentioned in a couple of CMake provided find modules: >find -maxdepth 1 -type f -name "Find*.cmake" -not -name FindPkgConfig.cmake -exec ugrep -HFe PkgConfig {} + | cut -d: -f1 | sort | uniq | sed s/..//;s/\.cmake// FindBLAS FindCURL FindCurses FindEXPAT FindFontconfig FindGLUT FindGSL FindGnuTLS FindImageMagick FindLAPACK FindLibXml2 FindLibXslt FindLibinput FindMPI FindOpenSP FindOpenSSL The prevalent method of discovering packages is via the package provided config scripts, which of course have to come from upstream. Kitware stopped adding new find modules, because they are not worth the maintenance effort (e.g. find modules require maintaining a list of versions like for Python or Boost) and instead upstreams should provide a proper CMake package. pkg-config also really only works in the Linux bubble. CPS[1] is trying to bridge the gap here if you are interested. [1]: https://github.com/cps-org/cps https://github.com/cps-org/cps
    • mdaniel 3y ago
      I dunno why you linked to the specification repo, since reading over it and its included sample made it seem like the "current editor in chief"'s fever dream of JSON all the things Only by going up to the repo listing does one find the actual implementation that alleges to replace pkg-config however <https://github.com/cps-org/cps-config#status https://github.com/cps-org/cps-config#status> seems like "well, good luck" for the problem they're trying to solve. I mean, they couldn't even write down what does or doesn't work in order to know if I should bother learning its snowflake json schema? Not even a $(cps-config --import) to port over the bazillions of .pc files out in the wild
• helloiamsomeone 3y ago
  The software distribution side of CMake is there and it serves many needs, so you can't really get a clear answer here, because only you know what you really need. Package discovery for example can be done with the CMAKE_PREFIX_PATH[1] command line cache variable, which is a list of prefixes where find_*() commands will go looking for things. But if you are putting your own install prefix together, or are using a system prefix, then CMAKE_INSTALL_PREFIX[2] can also serve that purpose and it will also set the default install prefix for cmake --install. You can also control discovery on a per find_*() command basis using various environment and cache variables, all documented in their respective documentation. For example, see the numbered list in find_package's documentation[3]. Setting RPATH can be done at a project level using the CMAKE_INSTALL_RPATH[4] variable. However, if you have both executables and libraries in a project, you might see how that may not be the most useful approach and instead you'd want to reach for CPack scripting (via CPACK_PRE_BUILD_SCRIPTS[5]) to setup RPATH separately for things going in /bin and /lib. Software distribution is messy and CMake provides tools to deal with things, but you have to know what's the most appropriate soltuion for your case. [1]: https://cmake.org/cmake/help/latest/variable/CMAKE_PREFIX_PATH.html https://cmake.org/cmake/help/latest/variable/CMAKE_PREFIX_PA... [2]: https://cmake.org/cmake/help/latest/variable/CMAKE_INSTALL_PREFIX.html https://cmake.org/cmake/help/latest/variable/CMAKE_INSTALL_P... [3]: https://cmake.org/cmake/help/latest/command/find_package.html#config-mode-search-procedure https://cmake.org/cmake/help/latest/command/find_package.htm... [4]: https://cmake.org/cmake/help/latest/variable/CMAKE_INSTALL_RPATH.html https://cmake.org/cmake/help/latest/variable/CMAKE_INSTALL_R... [5]: https://cmake.org/cmake/help/latest/module/CPack.html#variable:CPACK_PRE_BUILD_SCRIPTS https://cmake.org/cmake/help/latest/module/CPack.html#variab...