[Development] Future of QBS

[Konstantin Tokarev]

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
>>  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 at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Regards,
Konstantin