What would you suggest instead? This is honest, not sarcastic. Cmake can be very powerful, and I don't know of a better option. For instance, it can even be set up to download the latest binary dependencies, which is very useful.
Downloading the latest binary dependencies is (IMO) not a good idea. You should download a known working version with a fixed hash. This will avoid unexpected version mismatches in production. When you want to upgrade, make it explicit.
As for a better alternative, I would suggest Bazel or Buck.
I meant the latest I have pushed to a specific server I run. This means I can push up and everyone working on the project can fetch them easily. It requires intervention, and I wouldn't push until I've tested thoroughly and made necessary changes.
I appreciate the recommendation, though it seems that bazel is heavily focused on java.
That approach has a scaling problem because it requires the central server not to forget to verify the new version against all of the users. Instead, I think that upgrades should be decided on the user side. That is where the tests etc. live.
Bazel is a multi-language system whose focus is actually on C++. This is because other languages have much simpler compilation models.
I don't see why it would be a downside to have additional language support in your C++ build-system. For example, what happens when you want to do Android?
Upgrades are basically decided by the user by updating their cmake config. It can check a specific page on the server and compare with a page in the repo to see if an update is necessary. The central server doesn't have to do anything, it's just dumb file hosting.
I've got nothing against additional language support, though having to install java to use it is a bit painful. I'll take a look at it; I appreciate the recommendation.
You originally commented that cmake was awkward and required "gluing together". I'll agree that the syntax is a little alien to those of us with a background in c-like syntax, but it's never seemed that clunky. Any reason why?
> Upgrades are basically decided by the user by updating their cmake config.
So why not hash the remote file to ensure integrity, and make the server an immutable store?
> I've got nothing against additional language support, though having to install java to use it is a bit painful. I'll take a look at it; I appreciate the recommendation.
I would prefer if they did not use Java also. However, you do not need to install a JVM to use Bazel since it ships with one internally. To the end user, Java is just an implementation detail.
> I'll agree that the syntax is a little alien to those of us with a background in c-like syntax, but it's never seemed that clunky.
This was all I was trying to say really :)
Looking at the repo, I think it would be considerable tweaking to take a dependency on Nfhttp when you already depend on some of its dependencies. With Bazel (and similar) you have a clear way to glue things together ("workspaces") so you would just ensure that all dependencies take the same workspace.
CMake ergonomics is death by a 1000 cuts. The syntax is unpleasant and the error messages are very poor.
