[Development] Future of QBS

[Konstantin Tokarev]

16.10.2017, 16:08, "Ulf Hermann" <ulf.hermann at qt.io>:
>>  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).
>
> You could also argue that build systems should not use turing complete languages, so that other tools can get an idea of what they're doing without exercising the halting problem. However, apparently Meson fails at that, like so many others.

This problem is solved by having access to full "project" model from the same language. E.g. this is how I implemented Premake plugin for Qt Creator a while ago: added Lua code to traverse Premake's project structure, and run it with all of Premake from inside Creator's plugin, by linking liblua.

I think this is a good compromise. Alternative is using pure XML (e.g. ant) or JSON (e.g. gyp) to describe projects, which convenient for tools but inconvenient for humans.

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

-- 
Regards,
Konstantin