17.10.2017, 05:06, "Kevin Kofler" <kevin.kof...@chello.at>: > Konstantin Tokarev wrote: >> I have no real experience with Meson, but at least it has following >> advantages: >> >> * Its language is typed(!), > > CMake also has a concept of types. In particular, the cache variables (i.e., > the variables you can set on the command line, which are also cached across > invocations) have a type.
Maybe, but when script is running, everything behaves as a string in fact. Hell, it doesn't even distinct strings and target names. > >> has native support for arrays(!) > > That is what the CMake LIST command is for. Oh really? CMake lists are just concatenated strings with ";" separators inside, and there are cases when you have to take this fact into account. > >> and functions/methods have first-class return values(!) > > The CMake pattern of taking a result variable name (which is written to via > indirection) does the job and also allows having more than one return value. > >> * Its language has native support for properties, with syntax that really >> looks like properties in another languages > > That is what the GET_*_PROPERTY and SET_*_PROPERTIES CMake commands are for. > The verbose syntax allows you to see immediately what type of object you are > getting or setting properties of. Try doing some non-trivial operations on properties, e.g. appending value if it is not present in the list already, or remove some value from the list, and code quickly becomes unhealthy > >> * It is target-oriented from the start and is not so burdened by legacy >> ways of doing things wrong, which plague old CMake projects and confuse >> newcomers > > CMake is a mature tool with a long history, so of course it has to be > backwards compatible. The fact that old projects still compile is a great > feature (CMake is a lot better at backwards compatibility than, e.g., > autotools) and should not be held against it. CMake does support newer, > better ways to do things. And makes very little effort to drop this legacy, even with major releases > > What will happen to Meson in a few years? Will it break compatibility with > all the existing projects using it? Or will it be just as burdened by legacy > functionality as CMake? It is one or the other. > >> * It is written in scripting language, so it's easier to add >> (and possibly distribute) new functionality without getting it through >> upstream hands first. > > Meson actually makes it a point that you should not do that and that being > implemented in Python is an implementation detail: > http://mesonbuild.com/FAQ.html#why-is-meson-not-just-a-python-module-so-i-could-code-my-build-setup-in-python > > Being written in a scripting language also means that it is slower than if > it were written in C++ as CMake is. Even in their own benchmarks: > http://mesonbuild.com/Simple-comparison.html > Meson itself takes longer to run than CMake (for Ninja output, which is what > Meson also outputs). (That said, the produced Ninja output is marginally > faster, enough to compensate the longer runtime of Meson. But that is > unrelated to the implementation language.) It's doesn't make much sense to optimize such tools hard: generator runs only when build system files are modified, and rest of the time incremental builds just execute ninja. Fact that cmake is implemented in C++ just makes it less extensible, and make it's ugly internal architecture even more rigid. > > Kevin Kofler > > _______________________________________________ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
