[Development] Future of QBS
annulen at yandex.ru
Tue Oct 17 11:49:22 CEST 2017
17.10.2017, 05:06, "Kevin Kofler" <kevin.kofler at chello.at>:
> Konstantin Tokarev wrote:
>> I have no real experience with Meson, but at least it has following
>> * 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
>> * 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
> 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:
> 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:
> 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
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 at qt-project.org
More information about the Development