At the end of the configuration step, there are 21 files in the CMake build folder and 10 files in the Meson build folder. For the record, CMake generates a 435 LOC build.ninja file, while Meson’s build.ninja is only 289 LOC. While with Meson: $ time meson meson-buildĪccording to this first test, Meson is faster than CMake to configure the demo project. But anyway here we go: $ time cmake -GNinja -DCMAKE_BUILD_TYPE =Debug. ![]() The elapsed time of the configuration step is not really relevant, since you usually run it only once. I cannot claim this is true in general, but it surely shows that Meson is not perfect and probably not “faster” than CMake, in general. What I found out is that Meson’s build time is actually higher than CMake’s. The test has been performed with the ninja backend. Libqmatrixclient uses CMake, but I stripped down its CMakeLists.txt just to be sure to compare a minimal CMake configuration with a minimal Meson configuration. It builds a C++ (static) library and a little example app that links to that library. I used libqmatrixclient as test project, since it’s not a trivial hello-world app yet not the most complex project ever. Someone said that Meson provides supposedly faster build times than CMake and I was quite surprised to hear that. Tomas Nagy published some benchmarks here: Waf was 12 times faster than SCons and about 20% slower than make.This question came up on reddit yesterday, since many projects have been porting their build system to Meson (most of them from autotools, some from CMake). True, but I prefer more power over less.Ħ. ![]() Other build systems complicates it by keeping configure and build separate.ĥ. Then due to the use declaration in the call to the program() method, the correct compile and link flags will be added.īecause it is all in one tool, it is very easy. This will add a configure check using pkg-config ensuring that gtk+ is installed. I think the use case for configuring and building with the same tool is very compelling. waf build" or "python waf build" Adding directories to $PATH isn't necessary.Ĥ. I'm very sure it is explained in the waf book: Ģ. It's 100kb so it's not a huge burden to check it into your repo. You are supposed to ship the waf script with the code. The code provided no obvious benefits to SCons aside from a little speed, and it was light years slower than CMake, autotools, or simple GMake.ġ & 3. Using the Python language encouraged developers to implement actions which were not idempotent resulting in changes which were not properly tracked by Waf.Ħ. And adding configuration options to `scons` via command line options always worked just fine.ĥ. ![]() `autotools` had thousands of recipes for `./configure`. `cmake CMakeLists.txt` borrowed syntax from the C preprocessor which people were comfortable with. There was never an overwhelmingly compelling case for `waf configure`. Perhaps you can blame this on package mantainers. ![]() Build scripts simply broke between Waf versions too often. but if you don't know better, it takes people by surprise.ģ. Developers had to add the root of the project to their $ for it to work properly. Consequently developers would find a lot of regressions in the syntax for builds.Ģ. Developers trying to use Waf never realized that they were supposed to check-in the python BLOB into the repository rather than using a system package. As a user who primarily uses SCons, I feel like my opinion of Waf is reasonably fair.ġ.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |