Comment by gravypod | Hacker News Reader

Comment by gravypod | Hacker News Reader

While CMake is verbose I don't think it's terrible. The complexity of building a simple flat source project vs a multi-stage build project scales very well. One thing that amazed me was how simple it is to script up the creation of generated libraries.

For school I had to generate a build step that would allow me to embed Duktap and link to a library called Glad. Both needed to be generated with a python script. Doing this was dead simple [1]. I didn't have to do anything crazy to locate the path to python, the source folders I want to output into, etc. CMake has magic for that.

Granted I spent just as much time reading the really horrible docs to find out how to use these magic features as it took me to complete the assignment. I think like many amazing technologies it's blocked by a steep learning curve and a long long history of worse ways of doing things. Every time you google for how to do something you'll get an answer from a different part of the project's lifespan.

[1] - https://github.com/gravypod/solid-snake/blob/master/CMakeLis...

This is a great introduction to CMake for a single project/repo. You could add a section on installing the project. Although that probably isn't required for the student projects.

What I'm still searching for is a nice way to build multiple repos, which have dependencies on each other, in a cross platform way, that's distribution friendly. What I mean by distribution friendly is: you shouldn't be bundling your dependencies.

But it's nice to compile your own dependencies and link to that for debugging. So I want something that easily allows the upstream developers to download, compile and debug their dependencies, but doesn't do that when distributions (Debian, Fedora) go to compile and release your code. And it'd be nice if this was part of the CMake, so new dev's don't need to run some bash script to get setup, or follow a long list of instructions in a document to download, compile and install said dependencies. I'd also like to keep my existing CMake as horrible as it is at times, I'm not sure if switching to Meson is really worth the effort. Especially since I'm still stuck with C/C++ anyways.

Daniel Pfeffier’s effective cmake talks about how to do that. Setup each project standalone and get the dependencies with find_package. Then create a superprojects thats add each dependency with add_subdirectory and override find_package to be a no-op for dependencies added with add_subdirectory, since the “imported” target is already part of the build:

https://m.youtube.com/watch?v=bsXLMQ6WgIk

Now, overriding a builtin function is not the best idea so in boost cmake modules we have a bcm_ignore_package function which will setup find_package to ignore the package :

http://bcm.readthedocs.io/en/latest/src/BCMIgnorePackage.htm...

Just watched that video, long but awesome. I'm not sure on how exactly his strategy is supposed to go, but it sounds like the superproject is another repo. I don't really want that. What I'm thinking right now is to use the same overall idea, but instead of a superproject, I use the same repo, and use: https://cmake.org/cmake/help/latest/module/ExternalProject.h...

But put that behind a flag, that defaults to off, so it doesn't interfere with the distributions. And it supports patching so I can patch whatever dependency's CMake, in the event that they don't (yet?) support the same strategy so it can work transitively without having to boil the ocean. Granted, you would need to write patch files, for basically all your deps initially because nobody else is doing it that way.

For reference, I'm trying to help convert an existing open source project from autotools to cmake, but at work I'm the resident cmake expert, and we have multiple products, which effectively are built as different 'distributions' (not always Linux based) so I've been searching for a good way to do this for a while, even though I just started contributing to OSS.

I was working on this topic a few years ago and one of the things I noticed was that a lot of software patterns that work on the source code level can also be applied at the library or project level. What you're describing is basically Dependency Injection and the super-project is a Container.

It seemed like such a good idea, but I quit working on large software projects about the time I thought of it, so I never got a chance to actually try it outside of toy projects. I'm glad to hear that somebody else independently discovered and pursued the idea. If anyone has written about how adopting this approach has worked out for them, I'd love to read it.

Hunter allows this using the HUNTER_DISABLED flag. https://github.com/ruslo/hunter

It looks like you're one of the people very involved with hunter. This also looks very interesting, since it's implemented as a set of cmake scripts, which I can just add to my module path... What's the advantage of using hunter vs ExternalProject?

I'll try to dig through the documentation later this weekend.

Since my work project is spread across so many repos, and is so complicated and my OSS time is so limited, even hacking together a prototype can be a decent time investment, so I'd appreciate any high level feature differences you can think of.

Yes! I started using it ~8 months ago and fell in love with its simplicity. Hunter aims to be a full package manager, so it strives to build a project and all of its depedendencies recursively. This is fundamentally different than just adding one external project and ignoring the depedencies (what ExternalProject_Add does). The downside is this forces Hunter to maintain many forks of original repos just to keep track of the dependency information. Meanwhile, Hunter basically guarantees rebuilds only when necessary and caches all library builds locally in the ~/.hunter directory. It really really simplifies the whole dependency management of a CMake project.

Reply on news.ycombinator.com