[Development] Future of QBS

[Konstantin Tokarev]

16.10.2017, 15:06, "Kevin Kofler" <kevin.kofler at chello.at>:
> Tobias Hunger wrote:
>>  I am still missing a comparison of qbs and *current* build system options.
>>  All I see is qbs vs. qmake and qbs vs. cmake 2.x. Neither qmake nor cmake
>>  is what qbs will be competing with by the time it is ready to be used in
>>  earnest.
>>
>>  So far we excluded most possible build systems on the grounds that they do
>>  not support the mixed host/target builds we do. That requirement is going
>>  away. So we have more options now. Just to name two: Bazel promises great
>>  scalability and reliability, meson claims to be simple and fast. Even
>>  CMake made a lot of progress since version 2.x.
>
> This is the first time I hear of Bazel, so it cannot be that popular. The
> fact that it is written in Java also makes it a poor fit for Qt, as it would
> make Qt depend on the huge Java stack to build.

That tool is made by Google and tailored for Google internal needs. As we've learned
with gyp, they don't mind to abandon their stuff next day when something more cool
and more tailored comes out.

>
> Meson is, as far as I can tell (I had already looked at it a couple times),
> mostly a CMake clone written in Python. I fail to see how it is conceptually
> any different from (let alone better than) CMake. It is mainly pushed by
> GNOME developers who are fed up of stone-age autotools, but apparently do
> not want to use the same thing KDE uses (CMake) just because KDE uses it.

I have no real experience with Meson, but at least it has following advantages:

* Its language is typed(!), has native support for arrays(!), and functions/methods have
first-class return values(!)
* Its language has native support for properties, with syntax that really looks like
properties in another languages
* 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
* It is written in scripting language, so it's easier to add (and possibly distribute) new
functionality without getting it through upstream hands first.

That said, I totally dislike the idea of inventing restricted DSL language for build system
instead of using general purpose language (like e.g. in QBS or Premake).

>
>         Kevin Kofler
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Regards,
Konstantin