![]() But the way it works is identical for every project using CMake. These get turned into project files/makefiles for the generator you choose. ![]() With CMake you use the language to do a specific set of defined tasks: finding things, toolchain and system tests, defining targets and target properties, and if you need some custom commands. It's a framework for writing a custom build system specifically for your project.Ĭontrast with CMake. ![]() Of course I have much more experience with Meson than CMake so there might be some tricks I don't know about but in my experience dealing with CMake is just more painful. In Meson it was dead simple, it's about 4 lines explained directly in the tutorial and it just worked. cmake and whatnot files and every single article about it does it slightly differently. My biggest issue with CMake is when it comes to all the extra overhead you have to include in your build file to make something installable, there's so many install and export commands to generate all the. I did encounter some issues with Meson too but not nearly as many as with CMake. Personally my experience is that Meson is at the very least easier than CMake and most of the time also rather simple in absolute terms. I'll preface this by saying that I have the luxury of mostly working with greenfield projects and being able to more or less choose my tech stack so this might be a bit biased. Now of course if the library in question only has a public include dir then Meson always forcing you to have 2 basically equal looking calls can be considered as a bit redundant but personally I don't mind and think it's worth the clarity.Ĭmake is not simple or easy, but neither is meson. in a single call effectively splitting it in 2 as well. In Meson the creation of the library (which also contains the private include directories) and the dependency creation (where you specify the public include directories) are 2 separate function calls, in CMake it's having PUBLIC. In CMake you just link the library object you created but this target_link_libraries call does not just link but also set include directories and some other stuff. As for why you can't directly use the objects returned by the library call there I think again this is about being explicit. The idea is that you can do dependencies: and it doesn't matter where those dep objects come from, they can be declared in the same project (possibly in a subdir), they can come from a direct dependency(.) call, or from a subproject (either directly or called as fallback). The fact that I need to create additional sections (declare_dependency) in a subproject that is a static library. From your comment I'd guess that the problems you encountered come from subdir vs subproject confusion by for example trying to use subdirs as subprojects? Of course I'm just guessing here but this sounds familiar to my first Meson experiences, if you have encountered other problems I'd be happy to hear more about your issues. Having a bunch of own libraries as sub folders in the project with subdir should work just the same as CMake's add_subdirectory and so far I never had problems with that. However the idea that all those external dependencies are collected in one place is something I agree with, you can also check the official reasoning here. In CMake this folder would usually be called "third_party" or something like that. ![]() Subprojects in Meson are the way to include external dependencies (or rather in the most common case it provides a fallback option in case the dependency is not installed system wide) and not intended for actual "subprojects" of your project. That the folder must be called "subprojects" is a bit unfortunate, I agree.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |