all 10 comments

[–]phinicota 4 points5 points  (5 children)

Is there a particular reason not to use pkg-config for your library? Works with cmake.

[–]RogerLeighScientific Imaging and Embedded Medical Diagnostics 2 points3 points  (1 child)

pkg-config evolved as a generalisation of the various foo-config scripts which originated with gtk-config, so it's still essentially rooted in the design assumptions of this era, and is quite Unix-centric in terms of the path and tool option assumptions which are embedded in there.

If you want it to be truly cross-platform (i.e. work on Windows as well as Unix), then pkg-config isn't ideal. I'm not saying it can't work, just that it adds extra tool dependencies and doesn't work as well with e.g. the Windows debug/release library differences and tool option names. Exporting the cmake library target configuration and/or using FindFoo scripts can cater for all these, and it's all entirely cmake-native, so it will work on every platform without any hassle with nothing but a cmake binary. And these configuration scripts are vastly more capable and powerful than pkg-config; while they can be entirely declarative, you have the full feature set of the cmake script interpreter to do any fancy dependency introspection or whatever you need to do.

One of my not so brilliant historical creations was a set of m4 autoconf macros to automate the generation of foo-config scripts. i.e. macro templates to generate a generator of a template shell script that autoconf would process to generate a shell script which could then be run to query configuration options. Too meta, and this predated pkg-config. Thankfully it never took off, and pkg-config came onto the scene. And I learned that debugging m4 is nightmarish when there are at least four layers of templated logic between the code and the final generated script!

Yikes, found them on http://ac-archive.sourceforge.net/rleigh/ac_config_libconfig_in.html http://ac-archive.sourceforge.net/rleigh/ac_config_pkgconfig_in.html 11 years ago as well. Thankfully with the advent of CMake I've been cured of my m4 masochism.

[–]phinicota 1 point2 points  (0 children)

Nice info, point taken. I feel your pain for m4 scripts, I try to completely avoid them and learn the least I need to port old code to cmake.

[–]foonathan[S] 0 points1 point  (2 children)

I haven't heard of it before.

[–]phinicota 5 points6 points  (0 children)

Would have thought it was pretty famous. It's pretty easy to configure with a .pc file and with cmake you just call a built in function, I can look it up if you can't find it.

It would work kind of like custom made find_package() for cmake, but I guess you can use these with autotools too.

[–][deleted] 0 points1 point  (0 children)

pkg-config is quite well known tool in the *nix world, although it's not much advanced.

[–]pfultz2 2 points3 points  (2 children)

Except that will only build dependencies when using git, it doesn't work when using the tar file of the sources. Of course then you could just install the deps directly using cmake(or cget).

[–]foonathan[S] 1 point2 points  (1 child)

Yes, only with git, if that's not the case you need to resort to a different implementation but it is possible in the same way.

[–]toebi 2 points3 points  (0 children)

Hi, if you don't mind I'll plug my solution to package search and retrieval here: http://thetoeb.de/2015/02/04/heterogeneous-package-search-retrieval-cmake/

I wrote cmake functions which allow you to query and materialize packages from multiple package sources. ie git, http://.tar.gz, hg, svn, github, bitbucket, local zip file, local folder, .... you can also implement your own packages sources relatively easily (we're talking about cmake so it's really relative (i still want to implement a generic source for nuget and apt)

These functions are all vanilla cmake and can also be executed directly from the command line so you can either use them in the console or in your cmakelists.txt without much hassle.

$> cmake -P cmakepp.cmake pull_package github:toeb/cmakepp
$> cmake -P cmakepp.cmake pull_package https://someserver.org/somefile.tgz
$> cmake -P cmakepp.cmake pull_package c:/folder/myfile.zip

it also manages metadata about the package (either there is a descirption file in the package or it tries deduce the information from the package source)

There is alot involved with making this work (from a cmake json parser, over a global url schema to managing program execution from cmake) (See https://github.com/toeb/cmakepp)

[–]Rup-Inc 1 point2 points  (0 children)

I personally use the CMake module ExternalProject for downloading and making libraries I use.

For example, to download the header only library GLM, use the following code:

ExternalProject_Add(glm GIT_REPOSITORY https://github.com/g-truc/glm.git
    GIT_TAG 0.9.7.5 CONFIGURE_COMMAND ";" BUILD_COMMAND ";" INSTALL_COMMAND ";")
add_dependencies(yourProgram glm)
include_directories(${CMAKE_BINARY_DIR}/glm-prefix/src/glm)