4 ms·

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

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.

weberc2 8y ago
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.
- humanrebar 8y ago
  > 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.

weberc2 8y ago

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.

humanrebar 8y ago
> 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.