CMake

ke --build build in under 90 seconds. Might have even been faster if I used ninja. I actually don't konw how to compile make from source on windows. I had a look, and apparently I need to ftp the source from a gnu mirror? > This kind of thing does not really distract you from anything. Adding something like that takes as long as it does to add a cmake check. Then the person who is compiling has to do -DENABLE_FEATURE=1. This isn't unique to cmake but a meta build system does more than just let you add defines.

rience, that does not entitle you to imply they must just be incompetent, which is what you've done. You might refrain from borderline personal insults in future. You've not substantiated the If a worker does awful things premise. I've written several well-functioning CMake scripts, always following the current best practices. My point isn't that it's impossible to do this, but that it's painful to achieve. > complaining about cmake because of its rudimentary BASIC-like scripting language is a huge red flag Writing scripts is the only way you can use CMake. > If your idea of using cmake is to write scripts, you're either aiming to do something extremely exotic and exceptional, like adding macros that magically support frameworks like Qt or conan, or I dare say you do not know what you are doing. Again, CMake is always script-driven. Anyway, this response is misguided. The CMake scripting language is not intended only for small and simple scripts. I already addressed this point last time. [0] CMake package-detection scripts are enormous, and fail to follow any kind of standard pattern. Just look at this official first-party CMake script and tell me this is how it ought to look. [1] It's a trainwreck. > you only need to call about half a dozen cmake functions to declare build targets and define it's properties, and you've already met over 95% of any project needs. If you make the tiniest error anywhere along the line, you will get mysterious failures rather than helpful error messages. You might even get failures which only affect certain platforms. I've encountered this several times, as CMake fails to properly abstract away all the differences between the Windows and Unix build+link models, especially regarding shared libraries. Once you've got your script working, it will look as if CMake properly abstracts away these differences, but the existence of such failure modes belies the illusion. A good metabuild system would aspire to make invalid states unrepresentable, or would at least help defend against common mistakes. CMake doesn't even try. It's fragile footguns all the way down. A recent example of a failure mode that simply wouldn't happen in a better system (I mentioned another previously at [2]): I'm seeing CTest passing the string WORKING_DIRECTORY to my test script, as a command-line argument. Presumably it's incorrectly handling the WORKING_DIRECTORY marker in the argument list of add_test. Am I doing something wrong? Perhaps, but not that I can tell. Presumably this failure mode is only possible because of CMake's awful approach to parameter-handling, and would not have occurred in a well-designed system. > If instead you're in the business of mangling makefiles with BASIC you should really take a step back and reconsider what you're trying to do because odds are you're doing it very wrong. You're blindly assuming I'm misusing CMake. When I write CMake scripts, I always try to follow the current best-practices. Again, I do not appreciate you assuming that I have no idea what I'm doing simply because I disagree with you. [0] https://news.ycombinator.com/item?id=24567450 [1] https://github.com/Kitware/CMake/blob/master/Modules/FindIma... [2] https://news.ycombinator.com/item?id=24203172

Make to figure it out, and the correct answer depends on the CMake version, despite that both pkg-config and CMake were first released in the year 2000.) Also, optional dependencies can be handled properly. I don't see how you could easily handle this with pure Make. [0] https://github.com/Kitware/CMake/blob/master/Modules/FindBLA... [1] https://en.wikipedia.org/wiki/Pkg-config [2] https://stackoverflow.com/q/29191855/

es and produce a header file of the values, helping the developer cope with the platform's quirks. (It might check for the availability of a compiler intrinsic, or something of that sort.) > In that case, either your dependency is correctly installed into your system (and then, by definition, it is automatically found by the compiler and the linker), or it is not. There is no canonical installation path for a Unix package. You're right that the linker can be expected to, well, handle the linking, but that's not the whole story. Different distros (and different Unix-like OSs) install things (such as header files) in different places. Even within a distro, installing a package from source (rather than through the package-manager) may result in it being placed in a different directory. On Ubuntu the convention is that /usr/include holds headers installed through the package-manager, and /usr/local/include holds headers for libraries installed from source. Of course, Windows isn't a Unix-like, and things have to be handled differently there. The configure script should figure out that stuff automatically, the user shouldn't be given a pile of errors to manually fix. They shouldn't have to make any source-code changes just to get things to build. Robustly portable scripts to find packages, can be surprisingly involved. [0] This is why CMake encourages us to write self-contained Find... scripts that be reused by other codebases. > Both of these things can be perfectly done with plain makefiles Doing so manually with raw Makefiles, isn't scalable. This is why systems like Autotools exist. The configure script handles this sort of machine-specific detail. Large programs may have dozens of dependencies. It may be a sizeable task for the user to fix them all. > The alternative is to have your build system to search around your disk for possible versions of the required dependency. This is a completely untoward behavior and in very bad taste. C and C++ are not like Java. There isn't a single idealised system that you can target. You are exposed to platform-specifics, and it's on you to cope with them. This is true both at the source level (good code doesn't rely on sizeof(long) giving any particular value), and at the build level. [0] https://github.com/Kitware/CMake/blob/master/Modules/FindIma...

currently generates any redo-ifcreate dependency information, only the redo-ifchange dependency information. This is a deficiency of the compilers rather than a deficiency of redo, though. That the introduction of a new higher-precedence header earlier on the include path will affect recompilation is a fact that almost all C/C++ build systems fail to account for. > I have written, but not yet released, a C++ tool that is capable of generating both redo-ifchange information for included files and redo-ifcreate information for the places where included files were searched for but didn't exist, and thus where adding new (different) included files would change the output. JdeBP, could you please release your tool under a free software license? I suspect it has fewer errors than the similar CMake approach [4]. [1] http://news.dieweltistgarnichtso.net/posts/redo-gcc-automati... [2] https://github.com/linleyh/liberation-circuit/blob/master/sr... [3] http://jdebp.eu./FGA/introduction-to-redo.html#CompilerDefic... [4] https://github.com/Kitware/CMake/blob/master/Source/cmDepend...

s knowledge base do now? Shouldn't clang work almost like mingw? But because it misses the "if mingw" branch, code that probably would have worked for clang will be skipped over.