CMake front-end tool

Development
22

It would indeed replicate the command line interface, in a sense, by forwarding some arguments on to CMake should the user supply them. That is the intention.

If the reasoning is that CMake is complicated to learn

No, that’s not the reasoning. The reasoning is that you shouldn’t have to “learn CMake” in order to get started doing development on a project. The first thing I want to do—always—is to build the project and run all the tests, if nothing else to ensure I’m starting from a clean baseline before I start making changes. Doing that ought to be the result of an extremely simple command. And then the edit/compile/test cycle ought to consist of two things: making edits and running that command again, from wherever some file in the project. You may have no idea what a difference this experience makes to development if you haven’t used bazel or Rust’s cargo or Swift’s package manager (or I’m sure any number of other modern systems), but it does make a huge difference to many people, as @camio says. It makes a huge difference even to people adept in the CMake ecosystem, which he and I both are (him more than me).

By contrast, working with CMake, even if you never write a line of CMake code, is incredibly painful. It’s not that it’s soooo hard; it’s a death-by-a-thousand-cuts thing, especially after you’ve experienced something better. The whole reason I started this thread is that I keep thinking “I shouldn’t have to deal with this.”

If you don’t find much value in this proposal, that’s fine; maybe it’s not for you. I’ve already invested more time than I’d like getting parts of CMake to work, and improving docs, and I have no personal interest in presets. This issue is currently at the top of my “itch list,” so if I’m going to spend any effort on CMake-related work, it’ll be on this. So, unless you’re complaining that I’m taking up other peoples’ time on this list by gathering input, isn’t the way you think time should be invested moot?

Your assertion that “users should still be using the official CMake CLI” suggests that maybe this project would be harmful if allowed into the general population, but if that’s what you mean I find it hard to accept. This is a slightly higher-level UI for CMake tools just like C is a slightly higher-level UI for an assembler. That sort of abstraction layering has always happened and it makes the world better. If it’s not me, it’ll be someone else.

If it makes you feel better you could view it as a way to gather usage experience for a possible—someday—official CMake CLI… but as I’ve said (and I may have misunderstood) it seems like CMake maintainers aren’t interested in features like these.

23

I use the greatest IDE (and OS, and kitchen sink) ever—Emacs :wink:

I have nothing against IDEs, but I don’t love the VS Code plugin, because if you want anything to happen, you have have presets in your project, which aren’t set up for per-user configuration, and are usually checked into the project, so if you have any personal or machine-specific needs, you have to edit those presets, which is problematic for reasons noted elsewhere in this thread. You also have to set up a “kit,” whatever that is.

The plugin ought to be sure that for most projects I can just load them up in VSCode and start using them without ceremony, regardless of platform or local machine configuration, using defaults I can set up once for all projects on my machine. So I don’t want to support “basically the same feature set.” I want to make something better.

24

That’s exactly what I was trying to deal with at the end of this post. This is intended to be a front-end explicitly for CMake, and it would be weird to use a name that fails to suggest some connection to CMake. I’m not gonna do that unless someone has a really brilliant idea that I can’t currently imagine, and if I don’t hear any guidance otherwise I’m tempted to just use cm, because I assume there’s no less-offensive way to suggest a connection to CMake. As I noted, there’s really no precedent for CMake ecosystem tools using an unpronounceable name like cm.

25

What a single wrapper tool like cm could offer, is consistency.

For the cmake command, -C specifies the initial cache. When you use the command to build a project, you can specify a build configuration with the --config option. With ctest, you can specify a build configuration with either -C or --build-config. But with cpack, you can specify multiple build configurations with -C, while --config is used to specify a configuration file.

I cannot say whether that is complicated to learn, because I learned it long ago. But what I can say, is that it is complicated to teach. I don’t really have a good answer when I get asked why it has to be that complicated.

1 Like
26

… consistency command line options:

          run: CXX=${{ matrix.compiler }} cmake --workflow ${{ matrix.sanitizer }} # with cmake v3.31

 # or this 4 lines
          run: CXX=${{ matrix.compiler }} cmake --preset ${{ matrix.sanitizer }}
          run: cmake --build --preset ${{ matrix.sanitizer }}
          run: ctest --preset ${{ matrix.sanitizer }}
          run: cpack --preset ${{ matrix.sanitizer }}
27

From the use of --preset ${{ matrix.sanitizer }}, I infer that this snippet is from a Github workflow and uses CMake presets, both of which require copying additional files to the project. Hence, this approach is unable to provide consistent behaviour across projects.

What we are trying to archive, is that developers can download the source code of any CMake project (the only requirement is a CMakeLists.txt file) and run

cm install

which will then configure, build, optionally test, and install the project, while all options (build directory, toolchain, compiler flags, etc) are read from the developer’s configuration.

28

I can’t imagine that would be possible.

I know so many cmake projects, most are different in style, state of cmake version used, directory structure, default setting, presets, workflows, …

see i.e. using build preset with ExternalProject_Add - #7 by fws

29

None of those should cause problems. Especially CMake’s version compatibility is exemplary.

Thanks for making my point! This is exactly the reason why I consider those three evil and I advocate against their use.

30

Please do not use the name cm for a third-party tool. It’s the natural choice for a possible future upstream name. Please don’t make it harder to create an upstream tool in the future by using the name now.

1 Like
31

I agree. Having one more wrapper reminds me of autotools: automake, then autotools, then run configure, then run make which calls libtool which wraps the compiler.

My experience building “other” cmake-based projects is actually that this was mostly quite easy. Sometimes the cmake files were not fully portable to the compilers I needed, but beside that I didn’t experience trouble.

1 Like
32

I would say “any CMake project written to work standalone.” There are probably many projects out there that are not set up to download and build their dependencies, to use defaults when definitions are not explicitly provided, etc. I don’t expect to make those “just work” in the same way, at least not without a lot of project-specific settings in the user config, which is not the goal.

However, if we make cm install and cm test work well enough, I think momentum behind making projects “just work” in this way will grow.

Brad, why aren’t you telling me what kind of name (that suggests an association with cmake) would be OK with you? It is it really just about cm? Is cmk alright? I’m not going to keep guessing forever and will eventually have to pick one.

FWIW #1: I don’t understand what makes cm a natural choice for an upstream name since as I’ve said such names are unprecented in the upstream. You don’t seem inclined to explain yourself but regardless I’m going to ask why you think it’s natural.

FWIW #2: At least one command-line tool called cm already exists, which makes it a suboptimal choice for any new tool.

That said, it seems to me that if you’re playing in the space of two-character command names, you’re very likely to collide with something existing, and someone else is very likely to come along and collide with you, even if your use is well-established.

33

I’m reluctant to suggest any cmake-branded names because I don’t want the tool to use one. There is no reason this tool needs to be branded with “cm” or “cmake” to be useful. “cargo” doesn’t shout “rust” but people still know it’s used to build Rust projects.

34

Is this out of concern that users will incorrectly assume it is provided by CMake maintainers resulting in (a) confusion of where to find support, and (b) dilution of the CMake brand? Are there any other reasons?

35

My primary concern is to avoid confusion with a future upstream tool, so I suppose (b).

Also, IIUC a goal of the proposed tool is to make the C++ build experience feel more like other modern languages that have official tooling. That seems like an effort worth its own brand.

36

They only know that because it’s officially part of the Rust ecosystem, i.e. it’s not a 3rd-party tool. The association is driven from the top.

I’m not trying to fix C++. The goal is to make the CMake build/test/install experience feel more like that of other modern build systems (e.g. bazel). I use CMake to build Swift projects. This tool has no tie whatever to C++; it is focused entirely and explicitly on CMake and its ecosystem.

Part of what makes “cargo” work as a name (aside from that it is endorsed by Rust) is that there are metaphors that relate it to its purpose: crates, packages, etc. It wouldn’t hurt for the tool we’re discussing to have a name like that, but what can we relate it to other than CMake and its ecosystem?

The only way I see to stay away from anything cmake-related in the name, without being misleading, is to pick a name out of thin air with no relationship to anything. I don’t see how that kind of branding works for a tool like this, which is specifically about cmake… and very transparently so for its users (i.e. cmake isn’t an implementation detail the way LLVM is an implementation detail of Rust)… do you?

Seriously, I’m making a good faith effort here to find a suitable name that will make you happy. I hope you can appreciate from what I’ve written here why I feel like I’m in an impossible position. Can you suggest another angle?

<joke>
Maybe the name bk would be an obscure enough reference to satisfy you? :wink:
</joke>

37

Okay, to make “cmake” feel like “bazel”/“blaze”, how about cmz?

1 Like
38

I don’t think I want to specifically make an association with bazel, and for some reason the z rubs me the wrong way… but if a name of that ilk is OK with you, what about cmx, ucm, or cme?

39

Independent of the name, I would like the test an implementation of your front-end tool, if it exists.

40

ucm LGTM.

41

@ClausKlein Thanks. It doesn’t exist yet. It’s too bad this whole thing became so focused on naming; I was trying to gauge interest and see if there were any functionality ideas I ought to be considering before embarking on implementation.