![]() ![]() Most of my issues with CMake so far were in fact fighting various projects/libraries that were very opinionated in how I should include them in the project - most will work with whatever you want to do, some expect you to add them as subdirectory (fine for me), some require you to prebuild and install them before including in the project or have their own dependencies installed instead of being added as subdirectory directly (annoying and hard to deal with, since I want all my projects to build with fresh dev environment install + a single git clone, without messing in env/OS). The "variables" point is just a subset of there not being one standard way of doing things you could rely on. But CMake really is horrifying for me to write, and I try to use smarter alternatives like Evoke whenever I can. It's close to a de-facto standard in the community, and I do think that having a standard, even if its bad, is net better than not having a standard. Of course, there's a lot that CMake does do well, and that's why it's so popular. In my opinion, that should happen automatically, but not only does it not happen, but you have to write the code to do the actual copy yourself. It is pretty obvious that after the shared library is built, it should be copied to the executable folder so that it can be found on the search path when the executable is run. Let's say you have two projects in your build, one that's a shared library and another that's an executable that is marked as depending on it. Getting CMake to find the files you want to compile takes real work. Separating your includes and sources takes real work. cpp files and maybe their headers in a flat directory with the CMakeLists.txt file? That's because the moment you want to do even the most basic "real" project, it's actual work to get CMake to just build your projects. Do you notice how the majority of CMake tutorials will only ever cover the most trivial C++ project? One or two. ![]() There are straight up parts of the language itself that are bad and should not be touched. Note that this is not like C++ where there are ways to abuse the language to do bad things. In fact, there's a guy who makes an honest $30 just teaching you what parts of CMake you should use and what parts you shouldn't. This means in learning CMake, you will probably spend just the first week learning all the wrong ways to do things before someone tells you the right way to do it. Unfortunately, they're bound to leave all of the old error-prone methods in the language still because if they ever removed them all hell would break loose. The CMake team has made some attempts to make improvements to the way things are done. If you have two packages with the same name they will just overwrite each others variables.Ä«ackward compatability hell. If Eigen is on my machine (using find_package(Eigen3)), will EIGEN_FOUND, eigen_FOUND, EIGEN3_FOUND or eigen3_FOUND be set on my machine? (Hint, it happens to be documented well for Eigen, but not for most packages). When you run find_package, the result variable will be stored (silently) as whatever the package maintainer decided it should be. Continuing the point above, it's completely specific to the package you're using what the name of the result variable letting you know if something was found or not will be. If you deref a string and it doesn't have spaces in it, you don't need quotes, but if it does have spaces you do. Actually dereferencing a non-existent variable is a standard idiom in the language to determine function results. You can dereference any string you want, and there will be no errors if you dereference something that doesn't exist. set(x, "a b c") - this looks like a string but is actually a list of strings. ![]() The language for CMake has some of the worst syntax, in my opinion, ever created. Developers who began with other languages and then picked up C++ are (as in my opinion) horrified with CMake, for pretty easily articulatable reasons. C++ developers who started with C++ usually have adapted to CMake and find it to be an improvement over what they know (because what they know is also similarly complicated and twisted). ![]()
0 Comments
Leave a Reply. |