Qbs 1.8 Released -- Planned To Replace QMake Build System In Qt 6

[phoronix]

Phoronix: Qbs 1.8 Released -- Planned To Replace QMake Build System In Qt 6

Besides releasing Qt 5.9 RC2, The Qt Company is kicking off this new week by the release of Qbs 1.8 as their new build system...

http://www.phoronix.com/scan.php?page=news_item&px=Qbs-1.8-Build-System

[bitman]

NIH eh? Why cant they just use existing build system and focus on their product instead?

[bug77]

NIH eh? Why cant they just use existing build system and focus on their product instead?

NIH or not, a build system built (pun intended) around a specific product is at least a bit smelly.

[cipri]

I was wating for QBS since years to be able to compile a library!! I guess it still can not be used to build .so or .a files. Not to mention the bugs that are not fixed in years. My advice, not use any QBS nowhere!

[peppercats]

NIH eh? Why cant they just use existing build system and focus on their product instead?

because the available ones aren't very good for most uses?
They've outlined why cmake doesn't fit their needs, it provides nearly zero information needed by IDEs for managing C++ projects.

[lunarcloud]

Wow. Happy for Petroules that Qbs is getting good enough to ship and replace qmake. Went to college with that dude.

[kpedersen]

They've outlined why cmake doesn't fit their needs, it provides nearly zero information needed by IDEs for managing C++ projects.

CMake is open-source. They should make it fit their needs. A non standard build system is not only going to disappear within a couple of years but makes integration into actual projects almost impossible.

Why do GUI systems (and game engines) feel that they are more important than other software projects and try to take over the entire build process?

[Noee]

I was wating for QBS since years to be able to compile a library!! I guess it still can not be used to build .so or .a files. Not to mention the bugs that are not fixed in years. My advice, not use any QBS nowhere!

Where do you get this idea, please stop spreading dis-information? I've been using QBS for almost two years with my Qtcreator projects, (building .so and .a) scores of times per day for these particular products.

Here is a very small example of building a lib as dyn or static depending on debug/release

import qbs

Product {
    name: "mcws"
    cpp.cxxLanguageVersion: "c++14"
    cpp.debugInformation: qbs.buildVariant == "debug" ? true : false
    type: qbs.buildVariant == "debug" ? "dynamiclibrary" : "staticlibrary"

    property bool searchtimer: false
    property bool mpris: true
    property bool dbus: false
    property bool incltest: false

    property stringList commonDefines:
        [ 'LIBMCWS_LIBRARY'
        , 'QT_USE_QSTRINGBUILDER'
        , dbus ? "HAVE_DBUS" : "NODBUS"
        , mpris ? "HAVE_MPRIS=1" : "HAVE_MPRIS=0"]
    Properties {
        condition: searchtimer
        commonDefines: outer.concat("SEARCH_TIMER")
    }

    Depends { name: 'Qt'; submodules: ['network', 'widgets','qml', mpris || dbus ? 'dbus' : ''] }

    // Version #s for clang
    cpp.compilerVersionMajor: 4
    cpp.compilerVersionMinor: 0
    cpp.compilerVersionPatch: 0

    cpp.defines: commonDefines.concat(cpp.debugInformation ? ['DEBUG'] : ['QT_NO_DEBUG_OUTPUT', 'QT_NO_DEBUG'])
    cpp.includePaths: [product.sourceDirectory]

    files: ["pods/**", "images/**", "core/**", "search/**", "../mcwswidgets/proxymodels/*"]

//    Group {
//        condition: type == "dynamiclibrary"
//        name: "Resources"
//        files: ["images.qrc"]
//    }

    Group {
        condition: mpris
        name: "MPRIS"
        files: ["mpris/*.h","mpris/*.cpp"]
    }
    Group {
        condition: dbus
        name: "DBUS Interfaces"
        files: ["dbus/*.h","dbus/*.cpp"]
    }
    Group {
        condition: incltest
        name: "Load Test"
        files: ["loadtest/*"]
    }

    Group {
        qbs.install: true
        fileTagsFilter: product.type
    }
    Export {
            Depends { name: "cpp" }
            cpp.includePaths: [product.sourceDirectory]
        }
}

[Krejzi]

What a horrifying syntax. It almost makes Gentoo Ebuilds look sane.

[discordian]

This sit between the ubiquitous CMake with its rather ugly scripting language,
and the much cleaner and quickly spreading Meson. Good luck Qt, I think you are building your deserted island.

Pragmatically I use CMake, because it can do pretty much anything, and modules are freely available and can be dropped in own projects. IDE support is good, with even Microsoft(!) supporting it. Good help you dealing with more complex scripts, but setting up basic projects is still rather clean.

Msson looks clean and should technically be the prefered choice - if your needs are covered, there arent any modules you can drop into your own projects, you would have to extend the meson installation instead (chances are, if your needs are covered here, then they are aso covered with unextended CMake). IDE support is nonexistent.
Maybe in some years it will replace CMake at which I`ll switch, maybe it will never reach its popularity.

Now comes CBS, a conglomerate of Javascript, JSON and other stuff, no support anywhere and no apparent upswing vs meson. Its better then QMake, doh.
I really can`t see this taking off.