[Development] Future of QBS

[jeandet]

Hello,

My two cents as a Qt user and occasional Meson contributor.

I have the feeling that a Qt build system will always force the users
to choose between another tool they know but where the Qt support might
not be the best and a Qt focused tool with a good Qt support but they
will have to deal with external libs and might suffer corner cases.

What I like with Meson is the fact that Qt support isn't that bad and I
can easily link any other non Qt lib plus ship them with wrapdb. Then
cross compiling is really easy. 
Then I don't know for Qbs but small features like enabling coverage
with one simple option are nice with Meson.

As Qt user I started with qmake, I enjoyed writing projects with qmake
then I switched to CMake to make easier usage of non Qt libs and
config. Finally I switched to Meson and won't go back to CMake. I'm not
sure I would switch to Qbs unless it gets less Qt focused.

I still miss the point of making a dedicated build system instead of
contributing to more general build systems like Meson or even CMake.

Le lundi 16 octobre 2017 à 15:46 +0300, Konstantin Tokarev a écrit :
> 
> 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.
The huge difference is the fact that it is a description langage, no
function no macro.
> 
> 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).
Not being Turing complete is a choice and makes it really clear at the
end. I don't know Qbs but looking the doc and the rules stuff seems
like Qbs allows functions.
> 
> > 
> >         Kevin Kofler
> > 
> > _______________________________________________
> > Development mailing list
> > Development at qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development
> 
>