Hacker News Reader

> Here are some ways in which the CMake model is hamstrung... generating a build file for another build system

That's the critical selling point of CMake in my estimation. When I'm on Windows, I can generate a Visual Studio project and use its excellent debugger and code analysis tools. When I'm on Mac, I can generate an XCode project. Or a CLion project, or Makefiles, or...

Decoupling the build "recipe" from the build toolchain is critical for collaborative, cross-platform, cross-architecture projects, IMHO.

> No way to have targets that do not generate files and have other targets depend on those targets.

Isn't that exactly what an INTERFACE library is for? <https://cmake.org/cmake/help/latest/command/add_library.html...>

That’s just the worst of all worlds and makes for an equally terrible development experience for everyone.

CLion’s native support for CMake is the only thing that makes the IDE story palatable, but everything about CMake’s architecture resists treating CMake as a declarative format and performing that kind of intelligent integration.

First, why is it the worst of all worlds? I have a consistently good experience using CMake-generated Visual Studio projects. Second, what's the alternative? Having CMake manage the entire build, down to linkage? What benefits does that give over the current situation?

VS seems to be the most usable of CMake’s IDE output formats, but it still remains an awkward experience:

1) Two editable sources of truth, one of which is only sometimes overwritten when performing a target build, depending on whether the CMake inputs have changed.

2) Non-universal native IDE constructs can only be expressed if CMake supports them, and if you use IDE-specific CMake features.

VS is as good as it gets, and it isn’t that great. By comparison, Xcode project support is absolutely terrible.

CMake has a semi-declarative semantic representation of your project and its targets, but has to lossily translate that into a number of different, incompatible project formats, all of which are only capable of representing a different incompatible subset of CMake’s features. In several cases, CMake’s features behave differently (or not at all) depending on the generator being used.

I think GP already thoroughly elucidated most of the issues with this model; all of these issues fall out of the necessarily lossy, inconsistent conversion to incompatible output formats.

> I can generate a Visual Studio project

Except that you don't need to, Visual Studio has support for CMake built in (since 2017).

> That's the critical selling point of CMake in my estimation. When I'm on Windows, I can generate a Visual Studio project and use its excellent debugger and code analysis tools. When I'm on Mac, I can generate an XCode project. Or a CLion project, or Makefiles, or...

I've already addressed some of this in another comment ([1]), but you bring up more points, so I'll address it here.

CMake's model forces it to generate build files for other build systems. The better model does not force the build system to, but it also does not preclude doing so.

Separately from actually running a build (and that's important), my build system will be capable of generating files for VS, XCode, and other IDE's, but the files it generates will simply tell the IDE's how to integrate with my build system by telling them how to call it with the correct build profile. And yes, it will generate multiple possible build profiles, allowing VS users to select the solution the want to build from within VS.

But this means that my build system will not only integrate better with IDE's than CMake, it will still retain full control of actual builds.

This includes using debuggers and analysis tools, by the way. I wouldn't consider my work done on IDE integration until all of that is as easy as possible, and definitely as easy as CMake.

> Isn't that exactly what an INTERFACE library is for?

Maybe? It might be enough. At first glance (and I fully acknowledge that I could be wrong here), it seems like CMake expects the "target" to be a library of some sort. That's not the sort of thing I would personally want.

I would want to be able to depend on any target for any target.

But again, I could be wrong. I've never been able to understand the CMake docs.

[1]: https://news.ycombinator.com/item?id=33885476

> Generating a build file for another build system. This means that CMake always gives up control of the build. It can only tell the other build system the dependency graph and then sit back and watch. It can't regulate the build itself.

That is a hard requirement to using Visual Studio and XCode, which I wager account for more than 90% of C/C++ projects.

Sure, but doing so doesn't mean that the generating build system had to have the same model as CMake.

Here's how my build system will do it: the programmer will list default build profiles. Then the build system will generate Visual Studio or XCode files that include all of those default build profiles, but those VS or XCode files will simply call my build system with the correct build profile.

Thus, when a build is run from VS or XCode, my build system is still in full control.

In essence, instead of generating build files for use by other build systems, my build system will generate files to tell VS and XCode how to call my build system. It will tell VS and XCode how to integrate it.

My experience with build systems that do that is that there's consistently IDE features which just don't work correctly. The most obvious one is "build current file", which is very important for large projects and can't work without the IDE knowing how to build things.

I agree.

My build system will actually have a command-line option to reverse the dependency resolution. Instead of building a given target, updating its dependencies as necessary, it will build the default target(s), marking the files given on the command-line as "changed" and resolving dependents up to the default target(s).

This will mean that building the "current file" will be a simple command-line switch that can be part of the file generated for that IDE.

But yes, I'm going to put in a lot of work to make IDE's work as smoothly as possible.

Are you a solo dev? I wonder how much can be done compared to the teams behind Bazel and Buck(2)

Anyway, CMake is terrible - for all the reasons you have identified - so I wish you luck!

Yes, I'm a solo dev and not looking for contributors. My style is too eccentric to accept outside contributions.

Funny you should mention Bazel and Buck; I'm coming for them too! I'm also coming for Nix; I want its advantages to be easily accessible for mere mortals.

I think I can do better alone than those teams have because they have all made assumptions that weren't great. I'm learning from their mistakes.

Also, UX matters, and I'm putting a lot of effort into that.

But the other reason is that if you do Nix right, the capabilities of Bazel and Buck just appear.

Thank you for the encouragement!

> But the other reason is that if you do Nix right, the capabilities of Bazel and Buck just appear.

I'm curious about that... Nix has no notion of "providers" AFAIK, but these are key for optimization and composition of targets in Bazel / Buck(2)

Er, most of the capabilities of Bezel and Buck just appear.

That said, can you explain providers to me? I looked up the docs, and I'm no closer to understanding them.

I want to understand them and their uses do that my build system can have the same capabilities.

Disclaimer: I'm not a Bazel expert by any means

Every Bazel rule (e.g. cxx_library) has attributes and an internal implementation function in Starlark. The implementation can read the attributes and coordinates the work of actually calling programs (like Clang) and collecting the outputs. The collected outputs are exposed via a list of data-structures of type "Provider". When a target depends on other targets, it can see the providers of its direct dependencies. This allows targets to build on their dependencies. In C/C++, for example, the Providers contain the header files, the objects for linking etc.

I would definitely write (or at least read) a few Bazel rules before writing a new build system that improves on it!

> I would definitely write (or at least read) a few Bazel rules before writing a new build system that improves on it!

You have a point there; I didn't because everything I've seen is that people like the results of Bazel, but they hate writing rules, so Bazel rules seemed like something to not emulate.

But point taken.

And thank you for the explanation. It seems providers allow for multiple outputs on a target. My build system allows that, but bundling such outputs together is a good idea that I need to add.