Jake Petroules

Qbs 1.9 released

Published Tuesday September 5th, 2017
46 Comments on Qbs 1.9 released
Posted in Announcements, Biz Circuit & Dev Loop, Build system, Releases

Qbs (pronounced “Cubes”) is The Qt Company’s latest build tool, which aims to be the replacement for qmake in the Qt build system. In addition to its use within Qt, for our customers Qbs will also provide faster build times coupled with a rich feature set in order to reduce build engineering complexity and decrease time to market.

Today I’m excited to introduce you to the latest release of Qbs – 1.9. This is an important release with foundational new features.

What’s New?

In addition to the usual bug fixes and performance enhancements, this release includes two of the most foundational changes to the future of Qbs.

Language Improvements

The first of these is something we call Dependency Parameterization. Depends items can now be parameterized to set special module parameters for one particular product dependency. The new item type, Parameter, is used to declare such parameters in a module, while the new item type Parameters (note the ‘s’) is used to allow products to set default values for such parameters in their Export item.

So, what can dependency parameterization do for you? First, let’s step back and examine the meaning and usage of a Depends item.

Depends items are used to create a dependency between product A and product B, such that the target artifacts of the dependency can be used as inputs to the rules in the context of the depending product. In practice, Depends items have so far been used mostly to link an executable or library to another library. But a dependency is a very abstract concept, and can represent any type of relationship between two products. The fundamental problem is that whatever the meaning of the dependency, how that dependency took effect was only controllable from one side of the dependency relationship – the dependency’s side.

Qbs 1.9 allows this relationship to be controlled from the depending product’s side as well. For example, one of the products in your project may be a plugin which is implemented as a shared library. Your main application should depend on that plugin, because you want to ensure the plugin is built whenever the main application is, but you don’t want to directly link to that plugin because you want to load it entirely at runtime.

In Qbs 1.8, we would create a Depends items pointing to our shared library, like so:

Depends { name: "library" }

But there’s a problem – now our main application will actually link against the plugin shared library, which we don’t want. This is why we need to control the dependency relationship from the depending product’s side as well. In Qbs 1.9, we can now add a dependency parameter to the Depends item, like so:

Depends { name: "library"; cpp.link: false }

This tells Qbs that we want to depend on the “library” product, but don’t want to actually link to it. This gets exactly the result we want – ensuring that “library” is built whenever our main application is, but without creating a direct linking relationship between the two.

So how does it work? First, the cpp module in Qbs declares the availability of a boolean dependency parameter called “link”, using the Parameter item. Whenever a Depends item sets this property, its value will be applied to any input artifacts coming from the target artifacts of that product, when the current product’s rules are processed. The linker Rule in the cpp module then checks the cpp.link parameter of any dependent shared libraries and only links to them if it is true.

You might ask, why go through the trouble of extending the language in this way if we could just express within “library” itself that it should not be linked? Perhaps via using a different file tag for the output? The reason is that you might have multiple products A and B within your project that want to depend on another product C, but A and B both want to depend on C in a different way. For example, if C is a macOS dynamic framework, B might want to Depend on C by linking to it, because B is another library which depends on some of C’s functionality, whereas A is an application bundle that wants to depend on C by embedding it within itself, but not by linking to it, since the A application doesn’t directly call any functions in C.

The dependency parameter that we’ve added so far are cpp.link, cpp.linkWholeArchive, and cpp.symbolLinkMode. Check out the cpp module documentation to find out how you can use them in your projects.

Essentially, Depends items now provide a much more flexible way for build engineers to express the relationship between products, leading to more correct and efficient builds, without complicated hacks and workarounds.


The other important new feature we have is called Product Multiplexing. This feature replaces and is functionally a superset of the old profile multiplexing functionality we had previously implemented in order to support multi-architecture Android APKs.

The new implementation has been generalized to cover more use cases, and is a lot more powerful. Its primary function is to allow the creation of multi-architecture Android APKs and the creation of multi-architecture “fat” binaries and multi-variant frameworks (where a single framework can contain both a release and debug build of a library) on Apple platforms. We can also easily extend the multiplexing to more areas solely using QML, without having to modify the core build engine.

The problem with the old profile multiplexing is that it enforced a rigid project structure that was inherently dependent on the naming convention of the build profiles that were used. Such a structure wasn’t in keeping with our philosophy to make profiles optional, nor did it play particularly nice with how Qt Creator handles Qbs-based projects.

Enter product multiplexing: instead of multiplexing a product over multiple profiles, we now allow a product to be multiplexed over a number of more general properties. Currently, these are qbs.architectures (which maps to qbs.architecture), qbs.buildVariants (which maps to qbs.buildVariant) and qbs.profiles (which maps to qbs.profile, hence keeping a certain degree of backwards compatibility with the old multiplexing as well).

Product multiplexing works by examining a special property on the Product item called multiplexByQbsProperties, which can be set to the list of properties your product should multiplex over. For example, let’s say multiplexByQbsProperties contains two strings “architectures” and “buildVariants”. Qbs will then evaluate the values of qbs.architectures and qbs.buildVariants, which in turn may contain the values, [“x86”, “x86_64”] and [“debug”, “release”]. Qbs will then build the product N times according to the number of values in the matrix. In our example, 4 configurations of the product will be built: (x86, debug), (x86, release), (x86_64, debug), and (x86_64, release). If the Product’s aggregate property is true, the product will also be built a fifth time, where the values of the multiplexed properties are left undefined. The aggregate product will have an automatic dependency on the original four instances of the product, allowing it to collect and operate on their outputs artifacts.

The aggregate product is used in situations where the target artifacts of the individually multiplexed instances must be combined into one final aggregate artifact that makes up the overall product. For example, bundle products on macOS, iOS, tvOS, and watchOS use the aggregate product to create the bundle artifacts like Info.plist, PkgInfo, etc., which aren’t dependent on a particular architecture or build variant, and also use the lipo tool to join together the built native code for different architectures (like x86 and x86_64) into the final, multi-architecture “fat binary” that goes inside the app bundle or framework.

Due to its general design and easily extensible implementation in the build engine, we hope that in the future we can discover even more use cases for product multiplexing. One case I’ve considered so far but have not yet investigated is building multi-architecture app bundles for the Universal Windows Platform.

Deployment and Packaging

One of the interesting new features with this release is the ability to build macOS disk images with custom backgrounds and icon layouts.

Most applications on macOS are installed via a .dmg file, which is usually customized by a fancy image background and custom icon layout. The problem is, it’s quite challenging to construct such DMG files correctly. The custom background and icon layout relies on several undocumented proprietary file formats, some of which date back to the Mac OS Classic days, and which are even nested within one another.

Most of the existing tools to create DMG files do so by using AppleScript to manipulate the Finder graphically to generate the right icon layout, which is both unstable and incompatible with headless build servers since the necessary OS services to launch graphical applications may not be running at all. Other solutions will try to create the primary .DS_Store file manually, and commit to their source repository. This binary blob is difficult to inspect and edit, and might not be backwards compatible with older versions of the OS, depending on how it was generated.

The solution used by Qbs suffers none of these problems. It generates the necessary files programmatically, in an entirely reproducible manner, and there are no external dependencies that need to be separately installed and zero binary blobs committed to your source repository. It Just Works. Transform this:

AppleApplicationDiskImage {
    targetName: "cocoa-application-" + version
    version: "1.0"

    files: [
        // comment out the following line to use a solid-color background
        // (see dmg.backgroundColor below)

    dmg.backgroundColor: "#41cd52"
    dmg.badgeVolumeIcon: true
    dmg.iconPositions: [
        {"x": 200, "y": 200, "path": "Cocoa Application.app"},
        {"x": 400, "y": 200, "path": "Applications"}
    dmg.windowX: 420
    dmg.windowY: 250
    dmg.windowWidth: 600
    dmg.windowHeight: 422 // this *includes* the macOS title bar height of 22
    dmg.iconSize: 64

…into this:

macOS disk image built with Qbs

macOS disk image built with Qbs

Qbs even supports multi-language license agreement prompts that appear when the DMG is opened,  with full Unicode and rich-text formatting support. And no, you don’t have to deal with Carbon resource files from Mac OS Classic to do it!

In order to implement this functionality, we made use of several high quality Open Source Python modules (dmgbuild, ds_store, and mac_alias). I’d like to thank the developer, Alastair Houghton, for his hard work on and maintenance of these modules. The Qt Company has also contributed back a number of fixes and enhancements to these modules as part of the development of this feature.

Other New Features

  • Setting module property values from the command line can now be done per product
  • When rebuilding a project, the environment, project file, and property values are now taken from the existing build graph, which makes builds more self-contained and reliable
  • Rules now have a property requiresInputs. If it is false, the rule will be run even if no artifacts are present that match its input tags
  • Precompiled headers are now used by default if present in the product (cpp.use*PrecompiledHeader defaults to true now)
  • Added support for Unified Headers in the Android NDK
  • The property cpp.cxxLanguageVersion now gets mapped to MSVC’s /std option, if applicable
  • Added a new How-To section in the documentation with step-by-step guides on how to achieve common workflows
  • Context-sensitive help is now enabled for Qbs items in Qt Creator 4.4, which includes Qbs 1.9

Also, the loadFile() and loadExtension() function have now been formally deprecated and replaced by require(), as originally stated in the Qbs 1.8 release blog.

Try It!

The Open Source version is available on the download page, and you can find commercially licensed packages on the Qt Account Portal. Please post issues in our bug tracker. You can also find us on IRC in #qbs on chat.freenode.net, and on the mailing list. The documentation and wiki are also great places to get started.

Qbs is also available on a number of packaging systems (Chocolatey, MacPorts, Homebrew) and updated on each release by the Qbs development team. It can also be installed through the native package management system on a number of Linux distributions including but not limited to Debian, Ubuntu, and Arch Linux. An official Fedora package is in progress and should be available in a future release of Fedora.

Qbs 1.9 is also included in Qt Creator 4.4, which was also released today.

Do you like this? Share it
Share on LinkedInGoogle+Share on FacebookTweet about this on Twitter

Posted in Announcements, Biz Circuit & Dev Loop, Build system, Releases


Kai Mast says:

Why not CMake, Meson, or automake? There are so many build systems out there already.

Jake Petroules Jake Petroules says:

Two reasons: existing build tools don’t meet our needs, and we can bring innovation and productivity enhancements to an area that sees relatively little innovation because of doubtful outlooks like this. There’s also many aspects to build tool development that may not be evident to the average developer, unless you’re also a build tool developer.

The build tools you mentioned are actually rather low-level tools (meaning they only provide the bare minimum) whereas Qbs is a much higher-level tool which provides richer functionality.

I’d suggest reading the comments from the last blog post to get an idea of the why: http://blog.qt.io/blog/2017/05/29/qbs-1-8-released/, to avoid repeating the same answers again and again.

Zack says:

When does the development of QBS started?

Jake Petroules Jake Petroules says:

Development of Qbs began around 2011-2012.

tr3w says:

Sometimes I wonder if people also asked the CMake guys: “Why not automake?”

It’s also funny to list meson: it’s actually younger than QBS.

Kai Mast says:

But people actually use Meson.

Ernst Winthrop says:

So the people who use Qbs don’t exist because you say so. Right…

Ronnie says:

Now that the world (including Microsoft) seems to have settled on CMake, I’m not sure if there’s a place for yet another buildsystem. I’ll grant that Qbs deserves a fair trial and I’ll evaluate it in due time, but I strongly believe that for it to be any successful it needs to be decoupled from Qt and get its own website, community and so on (like Kitware did for CMake). Are there any plans in this direction? Otherwise, Qbs will always be “… oh yes that thing that comes with Qt” (like Qt Creator now is).

Jake Petroules Jake Petroules says:

The “world” settling on CMake is debatable – Microsoft *supports* it but it has by no means displaced or replaced MSBuild in their official tools, same goes for CMake remaining secondary to Gradle in the Android world, and it’s non-existent in the Apple world save for the Swift project, which probably only chose it because of LLVM). On Linux… yes, it’s probably effectively standard, but that’s not the only platform we have to care about.

You’re completely right that decoupling Qbs from Qt will be a major factor in its adoption and success, which is why we’ve designed it from the ground up to be toolkit and programming language agnostic.

As far as its own website, this is something we’ve talked about and is on my personal agenda to address in some way but we don’t currently have any official plans or timeline on that.

To be honest, I think it would be quite difficult to build a separate community from the Qt Project if we were interested in doing that, since that’s not something you can just “do”. It has to grow organically to a certain extent, and trying to maintain a separate set of technical infrastructure from codereview.qt-project.org and bugreports.qt.io is probably not worth it (at least as it seems right now). Consider other examples in the industry – the Apache Software Foundation was born out of the original Apache HTTP Server project, and grew to support a large number of other projects as well, none of which have a “stigma” of attachment to httpd. Remember, qmake always was directly and heavily tied to Qt. It’s not particularly useful for non-Qt or non-C++ projects. Qbs on the other hand is starting from a completely different path and outlook. I think it’s fine for Qbs to live under the umbrella of the Qt Project, and there’s no reason a sub-community couldn’t exist and grow within that framework.

But its own website and logo? Definitely!

Jean-Michaël Celerier says:

> The “world” settling on CMake is debatable – Microsoft *supports* it but it has by no means displaced or replaced MSBuild in their official tools, same goes for CMake remaining secondary to Gradle in the Android world, and it’s non-existent in the Apple world save for the Swift project, which probably only chose it because of LLVM). On Linux… yes, it’s probably effectively standard, but that’s not the only platform we have to care about.

You are saying that this is debatable but this is already more than any other single cross-platform build system.

JetBrains did a survey and CMake came out in front of makefiles in usage: https://www.jetbrains.com/research/devecosystem-2017/cpp/ at more than 1/3rd of developer marketshare.

Likewise for MS : https://blogs.msdn.microsoft.com/vcblog/2016/10/05/cmake-support-in-visual-studio/
” In our developer surveys, we have seen CMake constantly grow in usage year over year since 2012, surpassing in 2015 the make family (make/gmake/nmake) in terms of adoption.”

Even boost is migrating!

What would it take for you to accept that yes, the world indeed settles on CMake ? 50 % of usage ? 70 ? 90 ? Nothing ever gets such a marketshare in infrastructrure tooling like but everything would be so much more simpler if new alternatives weren’t added every two years instead of improve the existing ones.

Chris says:

The world had settled on gcc, then came clang….
The world had settled on apache, then came nginx…
The world had settled on MS Windows, then came Linux… (caugh, caugh, caugh….)
etc, …

Thomas says:

For me, this sounds like the desperate search for arguments against innovation, just because the world seems to have committed to something. However, it’s part of the human nature to constantly question things and develop new and better solutions. Good is good, but better carries it.

Jean-Michaël Celerier says:

Maybe I was not clear enough, but I am not at all against the QBS language itself. The language is nice even if in my personal opinion declarative build systems are only good for small projects which don’t do too much code generation & special cases depending on the target platforms.

What fills me with despair is restarting from scratch where all the progress that was made in cross-platform compatibility in CMake is lost; all the “find” modules, all the platform agnostic ways to set flags such as link-time optimization, PCHs, etc. There have been loads and loads of discussions on the CMake list of introducing another language on top of the CMake software that would fix cmake-lang’s quirks and a good enough proposal would certainly be envisaged for inclusion in CMake; a LUA proposal went quite far IIRC. But no, people have to start from scratch so that it scratches their own itches while contributing to an existing project could have had the exact same outcome in term of end-user experience, but with much less stuff to reinvent and greater compatibility with the existing ecosystem.

The other commenter takes the example of clang and GCC, but the first thing that clang did was copying most of GCC’s flags and behaviour so that the transition would be seamless ; and even still, clang is *far* for replacing GCC due to the ginormous amount of work to do, especially in terms of supported architectures and raw performance with max optimizations.

Likewise, sure, use nginx for the quick stuff, until you need to use one of the thousands extensions that only apache has, for instance for GIS, etc. Yes, the “hands-on” experience is much better, but the overall ecosystem ends up being divided and now most people have to learn *both* Apache and nginx.

Jake Petroules Jake Petroules says:

All of those who speak about “just” adding a new language frontend to CMake are not realizing that the front-end language is not the only issue. In fact, it’s probably not even the most important one. Replacing CMake’s language would not solve any of the inherent problems.

The CMake engine is fundamentally geared towards Makefile generation. Yes, I know there are other generators, but it was originally designed around Makefile generation and still retains the inherent limitations of Makefiles in its design philosophy. This has implications for both speed (and no, Ninja does not just let you wave a magic wand and see all of these problems fly away) and flexibility (there are certain constructs that make cannot express or makes very difficult to express).

I strongly believe that any build system that doesn’t make some form of multiplexing and aggregation functionality available (like Qbs 1.9, Gradle, and Xcode) is inherently limited in terms of real-world usage with the platforms that are relevant to us today and therefore a non-starter. That’s why virtually no one uses CMake for iOS or (full) Android projects. Yes, I know CMake supports Android, officially even, but only a small part of the process is handled by CMake, Gradle handles the vast majority because CMake just isn’t capable.

I’m also not sure why you think declarative based build systems are only well suited for small projects or why code generation has anything to do with it. Code generation is one of Qbs’s greatest strengths. We use this *very* extensively in the built-in modules. Can you give us an idea of what is a “small” and “large” project in your eyes? We’re using Qbs to build Qt Creator, which is a pretty decently sized project, and are porting Qt to use it, which is quite sizable.

I also disagree with your counterargument to the previous commenter’s statement “first there was gcc then came clang”. Yes, Clang has not replaced GCC yet but it is quickly happening and it will continue to happen for the foreseeable future. Clang might not have replaced GCC yet but for all we know, Clang may take virtually all of its market share at some point in the medium-term.

The status quo does not get a free pass against innovation simply because it is the status quo. Good is good, but better carries it.

GreenWolf says:

Is it possible to create Android and iOS applications ?

Jake Petroules Jake Petroules says:

It is. Ensuring good support for these platforms is a major goal of Qbs and was actually one of the primary driving reasons behind the two major features announced in this post.

In the future we will improve our documentation to talk specifically about how to target these platforms using Qbs and how to take advantage of the relevant features to their fullest extent (QBS-1183).

Markus says:

I am currently using qmake for everything, and quite many details of my qmake files come from the examples which are delivered with Qt. The major reason why I never tried cmake is because I don’t have a corresponding set of cmake examples with Qt. Searching the currently delivered examples (Qt 5.9.1) there is not a single qbs files inside 🙁

I would suggest to add qbs files (additionally to the existing qmake .pro files) to at least some of the example files, in order to demonstrate how a user can benefit from qbs.

What about e.g. a qbs project file for “Same Game” which includes deployment to any supported target platform including Android, and a project file for “Qt notifier” ? I believe these two alone would not cost you too much time, and would give any Qt Android developer absolutely enough information to start using qbs!

Jake Petroules Jake Petroules says:

This is in progress for *all* Qt examples. Unfortunately I can’t give you any date by when we might be finished.

Uwe says:

Yes, like Markus I have to say that good examples or the use of qbs in the Qt examples or in Qt real world projects would be the key for me to start switching over from qmake to qbs. I would really like to do this :O)

Chris says:

Good job, can’t wait to give it a try!

I think that people yelling “CMake, CMake, CMake” should give qbs a try, they will then understand how Qbs is way superior to CMake.

Have you plan to provide “helpers” for creating linux and windows installers? say based on QtIFW?

Jake Petroules Jake Petroules says:

Thank you for your support!

We actually already do support building Windows installers – there are dedicated modules for:

– Inno Setup – https://doc.qt.io/qbs/innosetup-module.html
– NSIS – https://doc.qt.io/qbs/nsis-module.html
– WiX – https://doc.qt.io/qbs/wix-module.html

Qt Installer Framework support will come in a future release and is being tracked here: https://bugreports.qt.io/browse/QBS-419

NoName says:

Why a new build system and not CMake? CMake is already a robust cross platform build system. Why do you want to reinvent the wheel?

Jake Petroules Jake Petroules says:

Ironically, CMake has very little Android support despite the fact that Android Studio uses it by default for native code. CMake has little to no support for most features on Apple platforms other than compiling and linking C++ code, and only very basic support for bundles. You have to write long, complex toolchain files to target any cross-compile environment, even ones (like iOS and Android) which are quite well known and shouldn’t require users to do that. Its language has a bizarre grammar that’s difficult to read and reason about. You need to be a build expert to use it. Everyone who uses it uses it only because it’s the status quo, and it’s mostly hated or disliked. That’s why not CMake.

There’s absolutely nothing wrong with reinventing the wheel (in fact the literal wheel actually has been reinvented numerous times throughout human history for varying good reasons). It’s about knowing when and how, and for Qbs… the time is right.

Jean-Michaël Celerier says:

> Ironically, CMake has very little Android support despite the fact that Android Studio uses it by default for native code. CMake has little to no support for most features on Apple platforms other than compiling and linking C++ code, and only very basic support for bundles. You have to write long, complex toolchain files to target any cross-compile environment, even ones (like iOS and Android) which are quite well known and shouldn’t require users to do that.

And how much time would have it taken to just add the missing bits to CMake instead of doing a build system from scratch ?

> You have to write long, complex toolchain files to target any cross-compile environment, even ones (like iOS and Android) which are quite well known and shouldn’t require users to do that.


if this is “long and complex” we seriously have other problems:

set(CMAKE_ANDROID_NDK /path/to/android-ndk)
set(CMAKE_ANDROID_STL_TYPE gnustl_static)

you have to be able to set this with QBS too at some point, else you will be limited in some way or another, be it performances, targeted devices, etc. Also Qt only supports android-clang in git while CMake had support for it for the last few versions.

Jake Petroules Jake Petroules says:

> And how much time would have it taken to just add the missing bits to CMake instead of doing a build system from scratch ?

Well, once you run into architectural limitations like I mentioned in my other comment, you have to start from scratch anyways. I don’t think extending CMake makes sense. It’s not the kind of legacy you want to carry forward if you can help it. Take the Mac OS 9 to Mac OS X transition as an example. Sure, they *could* have extended Mac OS 9 and fixed all the problems, but it was much easier to go with a solid design foundation (Unix) and add backwards compatibility from there.

> https://cmake.org/cmake/help/v3.9/manual/cmake-toolchains.7.html#cross-compiling-for-android if this is “long and complex” we seriously have other problems:

And that’s fairly new, and is a good step forward. However, what about compiling the Java code, generating AIDL files, assembling the APK, code signing, resource compilation, product flavors and multi-arch APKs etc, etc? CMake cannot do any of that, which is why it only has a very small role in the Android ecosystem and Gradle does most of the work. Qbs takes on *all* of the responsibility of both Gradle and CMake, and is therefore a much better choice for cross platform applications.

> Also Qt only supports android-clang in git while CMake had support for it for the last few versions.

Qt is a library, CMake is a build tool (unless you meant to say qmake?). The reason Qt and qmake only support Clang in Git is because Clang has had some issues with binary size preventing it from adopting it as the default configuration, so it hasn’t been a priority. Same reason why Google hasn’t completely removed GCC and libstdc++ from the NDK just yet. Once they do so, we’ll probably switch over.

Richard says:

CMake is a mess of a build system with poor usability and an error-prone language. When not using it on a daily basis, you will likely forget everything very soon. Not so with Qbs. It uses a very elegant and easy-to-remember declarative DSL (QML) where users can focus on WHAT they want to build rather than HOW. That’s really an innovation. Funny enough: Qbs made me understand how GNU Make is supposed to work.

nrw says:

First. I tried to activate precompiled headers and received error: Property ‘precompiledHeader’ is not declared. Qt Creator 4.4.0, Qbs 1.9.
Second. As i remember in “options->build and run->qbs” there used to be an opportunity to add new options. Now its impossible.

Jake Petroules Jake Petroules says:

As mentioned in the post, precompiled headers are now activated by default. Just add the file tag “cpp_pch_src” to your .pch file. See the cpp module documentation for more information.

Secondly, that option moved to “Options > Build & Run > Kits > [Kit] > Additional Qbs Profile Settings; the same functionality is still there, just in a different place.

N.A says:

Love to use Qbs in the future when it’s mature. Seems that happens when Qt 6 is released and i don’t know when it’s going to happen. I think one fascinating feature of Qbs is it’s syntax which is like QML. It’s incredibly easy to read and remember.
Thank you for your good work.

Chris says:

Adding Qbs to yocto shouldn’t be such a big issue. You “just” need to create a yocto “Qbs class”, which is not a difficult job.
Having say that, Qbs is not yet used much around, so i would say that “need” will drive this.
Qbs is very “flexible”, which is IMHO it’s weakness too. There is no “One way” to use Qbs.

“The Qt Company” already contributes to yocto (meta-qt5, boot2qt, …), so if Qt-6 switch to Qbs then expect a qbs base class from meta-qt6.

Anyway, being a bit negative here:
I have been complaining for years about yocto focusing on Qt3 and Qt4. Yes that’s right, yocto’s priority is about supporting the so-called “industry needs”, outdated guys still developing with Qt3 in 2017, just because the ‘biz’ guys are brain-less short-sighted money-driven morons….. [1]

Getting a bit out-of-scope here, but The Qt Company has made some move (recently), and meta-qt5 has improved thanks to the Qt community/company . My guess (hope) is that meta-qt6 will be an even better “The Qt company”/”Linux foundation” collaboration.

My 2 cents.

[1] https://www.mail-archive.com/yocto@yoctoproject.org/msg15883.html
Last commit to meta-qt3 was on 2016-08-29, a year ago!

Jake Petroules Jake Petroules says:

> Qbs is very “flexible”, which is IMHO it’s weakness too. There is no “One way” to use Qbs.

Can you elaborate? I haven’t seen this come up before and I’d argue that that supposed “problem” is far, far worse with CMake.

Mikael Kjaer says:

Any word on the status of a Yocto/OpenEmbedded integration for QBS. It is the only reason why I haven’t moved my research projects over to QBS yet is that I would have to add support for QBS to Yocto myself, because otherwise QBS is superior to QMake already especially for crossplatform projects. It might just be me that hasn’t quite understood how to do it, but I am guessing with the Embedded focus at the Qt Company this is at least something you’re looking at down the road.

Jake Petroules Jake Petroules says:

We’ve discussed this recently and plan to look into it at some point. The issue is being tracked in JIRA as QBS-1188.

Adrien Leravat Adrien Leravat says:

Thank you, keep the good work! Despite the relative lack of documentation and very limited IDE integration (yet), I like very much using Qbs in projects, it is quite refreshing. It offers huge possibilities while keeping things so simple, and I bet this will make a difference.

Christian Kandeler Christian Kandeler says:

IDE-wise, there is a bit of work to do in the wizards area. Otherwise, if you see shortcomings in the IDE integration, you might want to file a task at bugreports.qt.io.

nrw says:

Maybe I do not understand something, but now qbs does not allow you to create more than two precompiled headers in the same project and produces an error:
Output artifact ‘…gch’ is to be produced from input artifacts ‘file1’ and ‘file2’, but the rule is not a multiplex rule.

Christian Kandeler Christian Kandeler says:

Do you mean in the same *product*? That has never been supported, though I suspect it would be doable now. Can you file a bug report?

Igor says:

I am trying to build dmg with a new mechanism, but have next error:
The process ‘dmgbuild’ could not be started: execve: No such file or directory.

Could anyone help me?

Jake Petroules Jake Petroules says:

This is a known issue in Qt Creator 4.4.0. You can either use the command line version of Qbs, which doesn’t have this issue, or wait for Qt Creator 4.4.1 when it will be fixed.

Please see https://bugreports.qt.io/browse/QBS-1182 for details and a workaround.

Igor says:

Thank you. It works.

But could you explain how can i embed “macdeployqt” tool into the product build process? Early i had next steps for this:

1) “$QBS_EXE” build -d “$BUILD_DIR” -f “$PROJECT_PATH” -p “$BUILD_PRODUCT” –jobs 4 profile:”$QT_PROFILE_NAME” qbs.architecture:x86_64 release
2) “$QT_BIN_PATH/macdeployqt” “$BUILD_DIR/release/install-root/$BUILD_PRODUCT.app” -dmg -qmldir=”$SCRIPT_PATH/app/qml”

Jake Petroules Jake Petroules says:

In the long term, we have no intention of allowing macdeployqt to be used as part of a Qbs build process, since Qbs will provide its own features that completely replace macdeployqt.

For the time being, you should be able to create a Rule that takes artifacts tagged “installable” as inputs and invokes macdeployqt on an app bundle that was installed using the Qbs installation mechanism.

Merc says:

Either QBS or its documentation is incomplete.
1. Does QBS support multi-core CPUs?
2. How to set specific EXE fields like product name and copyright string.
Thus I didn’t bother.

Jake Petroules Jake Petroules says:

1. Qbs absolutely supports multi-core processors, this is a fundamental part of its design and quite frankly of *any* build tool (I’m not sure of a build tool that doesn’t support multi-core processors). That said, we’ll add a note about it in our documentation.

2. You create a .rc file with the proper fields and add it to your product’s files list, and Qbs will compile it into your EXE. In the future we’ll look into providing a set of dedicated properties to allow you to use Qbs to generate .rc files with these fields automatically.

Magnus Andersson says:

Qbs looks like an interesting build system. A good build configuration language is a key feature, and I think that Qbs has that. Fast incremental builds is another key feature, and it seems to be in place as well. However, for large code bases remote execution and caching (that is, the possibility to build in a cluster and cache artifacts) become important. Are there any plans to add these features to Qbs?

Jake Petroules Jake Petroules says:

This is something we’ve talked about internally but there are no concrete plans yet. In general though it should be possible to use Qbs with tools like distcc or icecream via the cpp.compilerWrapper property. Perhaps that’s something we can add to the FAQ.

Magnus Andersson says:

I think that the support for remote execution and caching in Bazel, is why Bazel will have an edge over Qbs for non-Qt users with large code bases. But these are complex features which are not needed for smaller projects (most users?), so I see how Qbs will be able to thrive without them.

My company has a code base of ~10 000 .c files, and we build very large binaries. Is there any reason for us to choose Qbs over Bazel?

Commenting closed.

Get started today with Qt Download now