I think I had the best experience with Meson/Ninja so far. I am also interested in using Nix for building. As for Cargo, I did not like how it recompiled all dependencies when I changed a warning flag on my project. I also found it unusable because it provided no way to check for the hash or signature of the dependencies that it downloads.
I don't think that I have ever been able to successfully compile a project that uses CMake. Its code is horrifying too, for example cmake-3.21.0-rc3/Modules/CheckFunctionExists.c contains
#ifdef CHECK_FUNCTION_EXISTS
# ifdef __cplusplus
extern "C"
# endif
char
CHECK_FUNCTION_EXISTS(void);
# ifdef __CLASSIC_C__
int main()
{
int ac;
char* av[];
# else
int main(int ac, char* av[])
{
# endif
CHECK_FUNCTION_EXISTS();
if (ac > 1000) {
return *av[0];
}
return 0;
}
#else /* CHECK_FUNCTION_EXISTS */
# error "CHECK_FUNCTION_EXISTS has to specify the function"
#endif /* CHECK_FUNCTION_EXISTS */
> I think I had the best experience with Meson/Ninja so far.
cmake lets you use ninja as the backend if that's your cup of tea. You can even set it to the default generator
, by setting the CMAKE_GENERATOR environment variable to ninja. (I have no meson experience, so can't compare it).
> I don't think that I have ever been able to successfully compile a project that uses CMake.
That's quite the statement. In practice, I've found
cmake -h. -Bbuild && cmake --build build
to work about 90% of the time. Far more luck than I've had with autotools.
> Its code is horrifying too, for example:
1) I'm sure I could find some horriffic code in meson too if I went digging. 2) The alternative to this is you having to write something equivalent in your own code, meaning that in my code I don't need to do stuff like [0] in my code to detect features; my build system handles it for me. 3) CMake supports more platforms and targets than I've ever seen in my life, and likely supports more compilers than are necessary. that's a blessing and a curse, but it means that if I write simple program to run on some crufty microcontroller with a bastardised gcc toolchain from the 90s, it's fairly likely that cmake supports it out of the box. Code like that is the price to pay for that level of support.
You missed the point. "__CLASSIC_C__" is not a thing (why they don't use __STDC__? I don't know, they don't seem to know either) and the syntax that they use inside that ifdef is.. not what people mean by classic C. It has been there for years and multiple people have pointed it out but they do not seem to care. The funny thing is that they do know how to use the pre-standard C argument syntax (as in https://gitlab.kitware.com/cmake/cmake/-/blob/master/Modules...), it's just that they do not want to fix it for that specific file for some reason.
As for
if (ac > 1000) {
return *av[0];
}
return 0;
I am not really sure what to say.
And then for CHECK_FUNCTION_EXISTS();, there are a few rare compilers that do not throw an error at compile-time if said function does not exist.
Also, I have been told that cmake-generated Makefiles invoke cmake itself, so you can't really generate portable Makefiles with it. In addition to that, I have been told that cmake takes ages to compile.
> meaning that in my code I don't need to do stuff like [0] in my code to detect features
> You missed the point. "__CLASSIC_C__" is not a thing (why they don't use __STDC__?
I dont know, I'm not going to defend it. Imnot going to do a line by line review of the file you picked, as I said I'm sure I can find awful code in bazel, meson, etc.
> Also, I have been told that cmake-generated Makefiles invoke cmake itself, so you can't really generate portable Makefiles with it.
Cmake generates a target for makefile that will re run cmake if your cmake file changes. If you're bukldong with cmake, you distribute the cmakelists txt, and treat the makefiles, ninja files etc as build intermediates
> In addition to that, I have been told that cmake takes ages to compile.
Do you compile your own make regularly? I've compiled cmake once or twice and it's not quick, but it's definitely doable (maybe 5 or so minutes?)
> I find that much better honestly.
The reason to use a build tool is to avoid hacks like that in user code. I would rather have cmake or meson or whatever my meta build tool is handle and test that logic, so I can focus on my library or application code.
> as I said I'm sure I can find awful code in bazel, meson, etc.
Oh, you have proof that person X murdered someone? I am sure I can find awful stuff that person Y and Z did!
[back in 2014] OpenSSL has heartbleed? Well, I am sure that I can find issues in libsodium if I looked.
> Do you compile your own make regularly?
No, my users however might need to once they have to deal with a cmake project.
> but it's definitely doable (maybe 5 or so minutes?)
I was told that it takes hours, though I might be misremembering.
> so I can focus on my library or application code.
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.
> Oh, you have proof that person X murdered someone? I am sure I can find awful stuff that person Y and Z did!
No - that's not what I'm saying at all. I'm saying that if you're holding X to a standard, you should hold Y and Z to the same standard.
> No, my users however might need to once they have to deal with a cmake project.
cmake is available from the package manager on basically every system imaginable, or as a binary (or source) download for a whole host of platforms. It's also widely used, so chances are a user is going to have it installed.
> I was told that it takes hours, though I might be misremembering.
If you're going to dogmatically claim that cmake is inferior, then you should at least verify the grounds of your claims are true.
I ran
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.
>And then for CHECK_FUNCTION_EXISTS();, there are a few rare compilers that do not throw an error at compile-time if said function does not exist.
check_function_exists() verifies that the symbol can be linked to rather than compile. That's why it gives it a bogus declaration of char CHECK_FUNCTION_EXISTS().
Funny enough I was trying to build a library yesterday that used check_function_exists() to detect the presence of some library functions. The project was set up to output a static library so check_function_exists() returned true for all the missing functions since it linked the test program without issue. https://gitlab.kitware.com/cmake/cmake/-/issues/18121
"cargo update" will update the packages along with Cargo.lock content. As for not updating them without a manual trigger, I consider it a feature, but I guess it's a matter of opinion.
I don't think that I have ever been able to successfully compile a project that uses CMake. Its code is horrifying too, for example cmake-3.21.0-rc3/Modules/CheckFunctionExists.c contains