[Raion]

I understand why people use it, but I still think it's incredibly unfriendly for command line usage and I generally don't care about portability to windows.

Moreover, I should articulate, I don't understand why we cannot have the best of both worlds if making a build system is not particularly difficult. I find the fact that it's not particularly easy to set up cmake makefiles as a mark against it, for instance. Autoconf is just ./configure, if the script is set up. If it isn't, you just run a few gnu commands and boom, it's set up. 

Furthermore I'm not saying that windows isn't important in the modern day, but I am saying that Microsoft has been stubborn about being more compatible with unix-likes and abandoning working tools for that is.. dumb. I have never used VXworks or any embedded or non unix stuff out there, so I can't speak for how common it is or how paramount using it is, but it seems that at least baseline posix compatibility is pretty widespread, as is a functioning command shell among most systems nowadays.

[jan-jaap]

I understand why people use it, but I still think it's incredibly unfriendly for command line usage [...]  Autoconf is just ./configure, if the script is set up.

With CMake it's just

Code:

cmake .

if the script is set up...

Autoconf was good for configuring projects between various (commercial) UNIX versions and UNIX like systems. It isn't good at all for almost everything else. Creating the macros requires knowledge of M4 and Perl. The commercial UNIXes have all gone the way of the dodo so it's solving a problem that no longer exists. Portability in 2024 means it runs on Windows, macOS and Linux (if you're lucky). If you're starting a project in this day and age and you hope to support Windows and macOS (and why wouldn't you, it's 90+ % of the market), Autoconf is a poor choice, and CMake isn't.

[Raion]

cmake applications usually are not straightforward. Unless I'm very recent change within the last year or two has been made you're not supposed to prep cmake within the same directory. Supposed to make a subdirectory, run cmake ../, then it will deposit the make/ninja file in that directory. If you need to pass options I've found no easy way to determine what options/defines are necessary/supported, kind of have to look through the cmake files for the application or hope that the developer documented them. With configure, it's --help.

I won't pretend that anything's perfect but as I've said above, I think it's foolhardy to try to be portable to windows. Everything from I/O, to even path separators have to be defined in your code because Windows wants to be different. And different set up here for me but, when I develop stuff, it's usually not intended for desktops. On the server side of things, Windows users only really use it because they have to for IIs and C#. If you're not using proprietary window stuff then there is no reason to use Windows server. Mac OS has no presence on servers really, and if it does you're smoking crack for using it in my opinion. It's not a very secure or well-designed operating system for server usage.

That leaves Linux, and niche OS options which are usually pretty trivial to add support for as long as you're not using Linux specific interfaces which you shouldn't be unless you're designing something that is specifically targeting Linux.

All of that said, I 100% realize that you are more experienced than I am in this area and that people are going to take my opinion with a grain of salt, but ultimately what I'm trying to vocalize is that there are multiple valid opinions on this topic. If cmake was intuitive, which it ain't, then it would be a mood point.