> Listing source files individually is what you're supposed to do, because not all build tools support globbing for files. To support this properly, cmake would need to re-run on every build to regenerate the files list... well, it's probably doable, with some work, but I expect there's just not the demand, I expect because most people are like me and would prefer to list their source files out by hand so they know where they stand.
Sincerely, have you spent much time with other languages? Very few require so much from the user.
It just now occurred to me that CMake isn’t so much of a build tool as it is a homegrown framework for making homegrown build tools. I don’t mean that to be insulting; I think it explains a lot of the differences of opinion about CMake; if you’re expecting a build tool like Cargo, you’ll be sorely disappointed, but if you’d like to make a one-off build tool for your project then maybe it’s not so bad?
That said, I probably spent 10-15 percent of my time managing CMake, and I wasn’t doing anything particularly novel; just trying to wire in some new library (like Qt back when everyone had a recipe that worked for their project but no one else’s) or testing framework (I remember GTest being particularly painful) or make builds reproducible or fetch libraries from a repository. Stuff that people in other languages get for free these days. I guess I just want nice things for the C/C++ communities as well.
I just like being explicit about which files end up in the build. It's a form of sandboxing, however limited and imperfect. (Build tools could go further to provide a more comprehensive sandbox, but meanwhile I have stuff to do and so I have to work with what's available.)
As well as automatically finding files to compile, if people working in other languages also want things downloaded during the build, dependencies automatically discovered, prebuilt dependencies retrieved, and so on, then good for them. But this is not stuff I want, and indeed I try to actively avoid it, to the extent feasible in the time available. (I typically try to ensure that all dependencies are built from source as part of the build, and that the source for each is included in the repo. This is usually fairly straightforward, and goes a long way towards eliminating annoying discrepancies between builds made on different computers.)
Anyway, this is not a moral question, and you must do what you want. These opinions are based on my experience, and if yours was different, I'm sure you had more fun. My point was just that if everybody feels like I do, then this might explain why CMake works the way it does, rather than some other way.
> This is usually fairly straightforward, and goes a long way towards eliminating annoying discrepancies between builds made on different computers.
With sincere respect, what you're describing is 'deterministic builds' and the features you say you dislike in other languages help to support deterministic builds in those languages, but it sounds like you're shunning those features because you think they hurt determinism? What you've described--vendoring dependencies--is a legitmate solution, but it has its own pain points, and many other languages have settled on a different model.
Even if you like the features you cite (and there's certainly validity to your opinion), CMake must be one of the worst ways to implement them. But I won't belabor the point; lots of people are very happy with CMake, but I won't touch it if I can help it.
I think alot of C/C++ devs have spent time in other languages, particularly python. And they generally have their own pathological problems, like pip.
Cargo is probably one of very few build tools that does almost everything correctly. So if you use almost any other build tools you're trading one set of problems for another. Granted, the issues aren't as hard to understand as C++ ABI incompatibilities but they are more or less just as hard for the tool to auto fix.
I think the overalls point is that the tool should support that language and so on. I'm sure everyone has their own horror cmake or autotools debugging story, but I think we are all very interested in a better way to solve the problem.
If you're point is, well you should just use a different language, you probably don't know the requirements well enough.
Yeah, I own the build system for our code which is all in Python. Pip is the package manager, not the build system, but your greater point stands: Python’s build tooling isn’t great (although pipenv is a significant improvement).
While few tools match up to Cargo, CMake is still uniquely unpleasant in my view. Most others aren’t fully imperative programming languages and at least have some ability or convention for locating sources. Many serve as a package manager or they dovetail nicely with a package manager. Go’s package manager story is a work in progress but I still prefer it to CMake (no contest).
My point isn’t that you should use a different language, my point is that CMake doesn’t compare to the tooling in other languages and there isn’t a compelling reason—it’s success is a historical accident, and I hope the community arrives at something better. I’m of the impression that there are other tools that are interested in solving this problem and I wish them luck.
> I hope the community arrives at something better.
Yes. That's the opinion of most everyone, including KitWare, it appears.
All of this is frankly a language defect. If working on build and packaging problems seems like a waste of time, then C and C++ are not good choices for you. Otherwise, dealing with all this is a job requirement, at least for senior engineers.
C++ is working on modules. Solving these problems seems to be downstream of that. I wouldn't count on de facto standard packaging tools for another decade. And there's a good chance that there will be forum threads about how annoying those tools are.
Sincerely, have you spent much time with other languages? Very few require so much from the user.
It just now occurred to me that CMake isn’t so much of a build tool as it is a homegrown framework for making homegrown build tools. I don’t mean that to be insulting; I think it explains a lot of the differences of opinion about CMake; if you’re expecting a build tool like Cargo, you’ll be sorely disappointed, but if you’d like to make a one-off build tool for your project then maybe it’s not so bad?
That said, I probably spent 10-15 percent of my time managing CMake, and I wasn’t doing anything particularly novel; just trying to wire in some new library (like Qt back when everyone had a recipe that worked for their project but no one else’s) or testing framework (I remember GTest being particularly painful) or make builds reproducible or fetch libraries from a repository. Stuff that people in other languages get for free these days. I guess I just want nice things for the C/C++ communities as well.