16.10.2017, 16:08, "Ulf Hermann" <ulf.herm...@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@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
