> I disagree with the fact that it is all that. Usually, what I see from people doing CMake wrong is downright malpractice. Something like "I can't be arsed to read about it for 30min, so I'll just trial-and-error and copy-paste stuff without thinking for 4h until it works, and then I'll say it's not my fault if it sucks.
I'll equate this to bash. I really wanted to learn it well and properly. I did, and I'd venture to say that happened at least 7 times (that I can remember of) and I forgot it each time because I don't use it often. I need it once or twice a month for a useful script and then it fades from memory. Sadface but those are the realities of the human brain (and I never wanted to resort to spaced repetition for bash in particular, though thinking of it now it was probably a much better idea than the other methods I tried for remembering all its quirks).
Ultimately I concluded that if something is quirky and needs you to put a special effort to remember how not to shoot yourself in the foot, then it's a bad tool. That's why I also abandoned `make`, learned `just` in literal 15 minutes and never looked back since.
After 23 years of a professional career and about 30 in total with computers I simply demand more quality of my tools:
- Have one and only one way to do thing X (also goes for programming languages though that's more difficult to achieve and not such a deal-breaker as it is with CLI / GUI tools);
- Make your most-commonly-used scenarios the easiest to do and the most trivial to remember;
- Make your tool and its most desired features easy to discover (via detailed help commands is one way, but there is also the "did you mean X?" etc.)
I am not taking jabs at CMake btw, I know exactly nothing about it. I am telling you that if I had to regularly do what I did with bash and make I'd ultimately conclude that it's a bad tool and will look to work around it... or I'll make a ton of shell aliases doing what I need from it and be very grumpy in the process (I mean: if I can't escape from CMake).
> That's bad faith. I learn to use all my tools properly.
OK, you got me, you are correct here. As admitted in the other comment, I am getting agitated by some of your comments because they seem to show lack of nuanced thinking. If I am wrong then I'd be happy.
> The more tools you know, the easier it gets to learn new ones.
...up to a point, after which you just get annoyed and want to scream "CAN'T YOU ALL JUST TALK TO EACH OTHER AND STANDARDIZE SOME STUFF ALREADY!".
I don't exaggerate when I say that I have learned no less than 200 CLI tools in the last 10-12 years, for many types of automating tasks (and even distributing them to clusters of machines), to wipe the arse of half-arsed niche databases some overly enthusiastic startup founder figured he needs to use as a competitive advantage (while he was on speed and LSD), to do data analysis for my own goals, to experiment with various task runners and build systems, and... yeah, maybe I should write some blog posts about it, it'll become too big.
My point is that what you say has an easily achievable peak after which you get just sick of everyone's crap. Just saying. Maybe you haven't reached that point yet.
> But most developers don't actually know the two commands needed to build a CMake project. Tell them to set an option with `-D` and they will start crying.
Now you are arguing in bad faith. :P I don't think you or I here should criticize those mystical "almost not devs" people just so we can feel smart. Using `-D` is something that every normal junior that I've coached will use and be grateful that I have showed them this "clever hack" (their words and they honestly made me laugh).
And if we try to be fair to all sides, many programmers want to, you know, only do programming, not learn a plethora of other tools that shouldn't have relevance to their work as much as they do. That's one of the reasons I gave up on C/C++ almost 20 years ago; I was doing much more effort making sure stuff compiles on several UNIX variants than actually solving any problems with code; the ratio was so bad that it was something like 70% to 30% on a good day; on some days it was 95% to 5% even.
It's all about striking a balance. Your comments come across as "git gud scrub!" to me and I can't ever let that go. It's demeaning and it hints at suffering from the main character syndrome (where you believe all others are stupid NPCs). And I am here to tell you that there are VERY GOOD REASONS why are you observing what you are observing and they are very rarely what you think they are.
I think we tend to agree, but you're more frustrated by the tools and I am more frustrated by the rants from people who clearly haven't put the effort (apparently not you).
Because it's easy to criticise CMake/Automake: we love to hate them. But in my experience, even though there are tons of valid points to make, many people who say "it's just because CMake sucks" are actually just making a mess and blaming CMake.
> Have one and only one way to do thing X
Agreed. To add some nuance though, most projects are perfectly fine by just using a minimal set of features in CMake: just use `find_package` and install the dependency on the system, or locally and learn how to find it with CMAKE_PREFIX_PATH and pkgconfig. I would even say that writing a custom CMake command is almost always a bad idea.
But to me it doesn't mean that you need to have one tool that does everything (and that also makes coffee). To me it's a bad idea to configure an entire CMake project to be run by gradle for Android. Mixing build systems makes matter worse, not better.
> Make your most-commonly-used scenarios the easiest to do and the most trivial to remember;
Sure, but the risk there is that many people hide the lower level because they try to "keep it simple stupid". Which IMO is wrong. Expose the lower level, but clearly do it in... a lower-level abstraction. So that advanced users can use the low-level, and others can use the higher-level. And usually it means: start with the low-level API. If it's good, maybe someone else will write an abstraction on top of it!
I am often frustrated because projects put a lot of effort into hiding lower-level APIs and then I'm stuck (and need to e.g. fork).
> That's why I also abandoned `make`
Note that I don't write projects with make. But it has merit, and I learned to understand/maintain projects based on it. I don't learn all the build systems under the sun, but make, CMake and meson (in the C++ ecosystem) seem valuable to at least understand.
The risk with introducing yet another tool like "just" is that you make "your" problem worse: it introduces a new tool. I am usually fine learning new tools, but in my projects I try not to introduce them: I use CMake or Meson because it makes sense to expect that C++ devs should understand them.
I'll equate this to bash. I really wanted to learn it well and properly. I did, and I'd venture to say that happened at least 7 times (that I can remember of) and I forgot it each time because I don't use it often. I need it once or twice a month for a useful script and then it fades from memory. Sadface but those are the realities of the human brain (and I never wanted to resort to spaced repetition for bash in particular, though thinking of it now it was probably a much better idea than the other methods I tried for remembering all its quirks).
Ultimately I concluded that if something is quirky and needs you to put a special effort to remember how not to shoot yourself in the foot, then it's a bad tool. That's why I also abandoned `make`, learned `just` in literal 15 minutes and never looked back since.
After 23 years of a professional career and about 30 in total with computers I simply demand more quality of my tools:
- Have one and only one way to do thing X (also goes for programming languages though that's more difficult to achieve and not such a deal-breaker as it is with CLI / GUI tools);
- Make your most-commonly-used scenarios the easiest to do and the most trivial to remember;
- Make your tool and its most desired features easy to discover (via detailed help commands is one way, but there is also the "did you mean X?" etc.)
I am not taking jabs at CMake btw, I know exactly nothing about it. I am telling you that if I had to regularly do what I did with bash and make I'd ultimately conclude that it's a bad tool and will look to work around it... or I'll make a ton of shell aliases doing what I need from it and be very grumpy in the process (I mean: if I can't escape from CMake).
> That's bad faith. I learn to use all my tools properly.
OK, you got me, you are correct here. As admitted in the other comment, I am getting agitated by some of your comments because they seem to show lack of nuanced thinking. If I am wrong then I'd be happy.
> The more tools you know, the easier it gets to learn new ones.
...up to a point, after which you just get annoyed and want to scream "CAN'T YOU ALL JUST TALK TO EACH OTHER AND STANDARDIZE SOME STUFF ALREADY!".
I don't exaggerate when I say that I have learned no less than 200 CLI tools in the last 10-12 years, for many types of automating tasks (and even distributing them to clusters of machines), to wipe the arse of half-arsed niche databases some overly enthusiastic startup founder figured he needs to use as a competitive advantage (while he was on speed and LSD), to do data analysis for my own goals, to experiment with various task runners and build systems, and... yeah, maybe I should write some blog posts about it, it'll become too big.
My point is that what you say has an easily achievable peak after which you get just sick of everyone's crap. Just saying. Maybe you haven't reached that point yet.
> But most developers don't actually know the two commands needed to build a CMake project. Tell them to set an option with `-D` and they will start crying.
Now you are arguing in bad faith. :P I don't think you or I here should criticize those mystical "almost not devs" people just so we can feel smart. Using `-D` is something that every normal junior that I've coached will use and be grateful that I have showed them this "clever hack" (their words and they honestly made me laugh).
And if we try to be fair to all sides, many programmers want to, you know, only do programming, not learn a plethora of other tools that shouldn't have relevance to their work as much as they do. That's one of the reasons I gave up on C/C++ almost 20 years ago; I was doing much more effort making sure stuff compiles on several UNIX variants than actually solving any problems with code; the ratio was so bad that it was something like 70% to 30% on a good day; on some days it was 95% to 5% even.
It's all about striking a balance. Your comments come across as "git gud scrub!" to me and I can't ever let that go. It's demeaning and it hints at suffering from the main character syndrome (where you believe all others are stupid NPCs). And I am here to tell you that there are VERY GOOD REASONS why are you observing what you are observing and they are very rarely what you think they are.