CMake front-end tool

[neundorf (Alex Neundorf)]

@dabrahams

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.

I have the same confusion.
Configuring VS code, which plugins recognize which “variables”, in which json files, what generator to use, etc., is quite confusing IMO.

[starball]

You don’t have to edit CMakePresets.json. Read the comment posted before you said this about CMakeUserPresets.json.

What if I’m using a different compiler? What if I also need to set a CMake cache variable?

Use CMakeUserPresets.json. It’s specced, so any frontend can use that spec. That’s what CMake Tools does, and what most of the big IDEs do- including VS and CLion.

[starball]

I’d suggest that you just build what you want. Make something that works for you. Show it to the people around you. If they’re interested, they’ll offer feedback, and you can choose to listen to them, or defend your own ideas, which is what you’re already doing (but it seems to me like you’re mostly doing the latter, which is especially why I think you should just go and do what you want).

[dabrahams (Dave Abrahams)]

@starball

You don’t have to edit CMakePresets.json. Read the comment posted before you said this about CMakeUserPresets.json.

The comment immediately preceding was posted by me, and the comment I was replying to doesn’t seem to say anything about that. Links help.

@starball

I’d suggest that you just build what you want.

Of course; I understand the dynamics of open source. I was hoping to gather some useful ideas that could save me time and inform my work; that’s how I like to do things. Most of my time here hasn’t been spent defending my ideas, but instead trying to pry information about acceptable naming out of Brad. But I agree the well here was drier than I expected from the get-go, which is why I hadn’t posted here in months.

[Bret_Brown]

For what it’s worth, I never stopped considering when and how to start work on a new front-end tool for driving C and C++ development.

I don’t feel the need to brand it specifically along with CMake. There are a few reasons for a new tool that is separate from CMake, but base requirements are driving them.

First, dependency management is one of the main features missing portable ergonomics in C and C++ development. CMake is at its best a build system, and while FetchContent has some popularity, I don’t believe it meets the interoperability requirements needed for modern software engineering tasks. I am happy to elaborate on this, but in short, tools and humans get confused by all of the FetchContent configurations in different files. Which one actually linked and why? How can one detect and correct dysfunction, like a CVE in a dependency?

That leads me to believe that we need a driver that provides a more end-to-end experience.

Second, I also believe for productive performance (caching!) and troubleshooting (reproducibility of outcomes!), we need some amount of precision and control in development environments. This, again is out of scope for CMake. It does not and should not (at this point) try to set up build actions in controlled, sandboxed environments.

Third, we need to cultivate an ecosystem full of packageable and portable projects. If we require some sort of exclusive project style, we rule out supporting projects like sqlite3, who have no interest in converting to the new thing, no matter how great it is. We need tech that can be configured to edge cases, not a tool that demands entire ecosystems be ported to its expectations.

That being said, I do think we are overdue for defining some basic, supported project structures and development workflows and supporting them. If some projects want hundreds of lines of procedural code in build scripts, fine, but a simple project consisting of a a directory of portable source files and headers should need little more than a small configuration file describing the intended support surface of the project: C++ versions, warnings that are checked, sanitizers that are used, etc.

[dabrahams (Dave Abrahams)]

@Bret_Brown Your perspective and mine are different:

• I have no personal stake in C and C++ development specifically.
• I want to make a tool that solves problems I have when using specifically CMake, and I think ucm is a reasonable name; I certainly would not like to rehash the naming discussion.
• I have no stake in cultivating an ecosystem, though I think it’s a good idea and I can see how a driver like what I’ve discussed would help.
• I don’t want to take on the burden of making something so configurable that it can work perfectly with every possible CMake project in its current form. Because CMake is an imperative programming language, I think that probably amounts to solving the halting problem.

Do you think there’s enough overlap in our goals and interests for a viable collaboration?

[purpleKarrot (Daniel Pfeifer)]

Here is a start: GitHub - purpleKarrot/cx: CMake Launcher

• Implementation language is Go.
• User preferences are stored in ~/.config/cx/config.<ext>. Supported formats include JSON,TOML, YAML.
• Options are still limited. Contributions are welcome.
• The project root is determined by looking for CMakeLists.txt files in parent directories and picking the one that is closest to the filesystem root (that is not the nearest parent).
• Build directory is still hardcoded to src/<build>. This should be changed.
• cx configure invokes CMake to create a build system.
• cx build from anywhere in the source project invokes cx configure if CMakeCache.txt does not exist and then builds the all target of the current directory. That may be cmake --build <build_dir> --target <subdir>/all or cmake --build <build_dir>/<subdir> depending on the generator.
• cx test from anywhere in the source project invokes cx build unconditionally and then executes tests that are defined in the current directory and below with ctest --test-dir <build_dir>/<subdir>.
• cx install from anywhere in the source project invokes cx build unconditionally and then installs targets that are defined in the current directory and below with cmake --install <build_dir>/<subdir>.
• cx open invokes cx configure if CMakeCache.txt does not exist and then opens the associated IDE of the generator if supported, like Xcode.
• cx clean deletes the build directory.

[dabrahams (Dave Abrahams)]

Whoa, Daniel my friend!

It’s so exciting that you started this project! I’m sure you’re in a much better position to drive it than I am anyway. One of the first things I wanted to raise was what the implementation language should be. I have nothing against Go—other than that I’ve never used it—can you say something about why it’s the best choice?

Best regards,
Dave

[leha-bot (Alex)]

Won’t mind if I will use that util in my prototype for cmake subcommands (there are only discourse thread about it: Feature request: Add support for subcommands like git and many CLI utils do (cargo, npm) - #2 by brad.king)

[marc.chevrier]

He seems unfortunate to choose a language not supported by CMake.

[Bret_Brown]

Do you think there’s enough overlap in our goals and interests for a viable collaboration?

Yes, though I want to focus on some polyglot dependency management issues first (the CPS project). In my experience, at least half of the ergonomic issues here are downstream of not being able to coherently declare a dependency.

As I said before, for simple workflows and projects, cmake --workflow gcc-debug is an effective one-liner. And the slightly more verbose cmake --preset commands can cover most of the remaining cases. At least well enough until we can develop tools prepared to make end-to-end build plans (including dependency fetching if needed) given some options, some defaults, and some user decisions.

Note for everyone in this thread: https://ecostd.github.io is unannounced but spinning up to exactly make a place to drive convergence in the C and C++ ecosystem, including for build systems like CMake. When I have concrete opinions about a cxxproject.tomlproject config file or the ultimate build workflow tool, I’ll be proposing RFCs in that context while asking for early adoption and feedback in communities like this one.

[purpleKarrot (Daniel Pfeifer)]

@dabrahams

I have nothing against Go—other than that I’ve never used it—can you say something about why it’s the best choice?

I am not even convinced myself that it is the best choice. The language is quite awkward, especially when viewed from a C++/Swift perspective. When you look at Swift, you clearly see that the language was designed by taking the C++ philosophy to the next level. Go, on the other hand seems like it was designed by reversing the C++ pholosophy.

• Everything is mutable.
• Containers have reference semantics.
• Errors have to be propagated manually.
• It is considered good style to prefer loops over algorithms.

But as you see, it is still possible to write software in it. I really recommend trying it. There is probably more that you can learn from it than by trying a language that is close to another language you already know. Also, the Cobra librarly is excellent for writing modern CLI applications. I didn’t know it before either.

@marc.chevrier

unfortunate to choose a language not supported by CMake.

We have enough CMake projects that we can use for dogfooding. What do you think would be the advantage of building such a tool with CMake?

I actually consider it an advantage to use an incompatible language for an alternative frontend that may inspire a future official frontend eventually. That way, there is no temptation to reuse existing code in the new frontend which could constrain the design choices otherwise.

[marc.chevrier]

Relaying on a language supported by CMake as the following advantages:

• No need to know some other development environments (i.e. development, test, packaging, …) which will greatly facilitate the contributions to a such project because CMake knowledge is, anyway, required.
• The development of a such tool can rely on the tool itself. So, the developers can validate very early any change of design or implementation…

And, finally, by using an incompatible environment with CMake, you definitively kill any chance that this tool be integrated as part of CMake.

[dabrahams (Dave Abrahams)]

The most important factors in choosing a language for this tool, off the top of my head, in roughly decreasing precedence order, IMO, are:

1. The number of desktop platforms on which the tool will run.
2. The dependency installation hassle and size implied for running it on these platforms.
3. Comprehensibility of the resulting code
4. Size of the resulting code
5. The dependency installation hassle implied for developing it on these platforms.
6. Memory and thread safety (this would be much higher if CMake weren’t already written in C++).

Maybe I forgot something?

[dabrahams (Dave Abrahams)]

@marc.chevrier

And, finally, by using an incompatible environment with CMake, you definitively kill any chance that this tool be integrated as part of CMake.

In what way is it incompatible? I think CMake is general enough that almost nothing is completely incompatible with it.