Christian Kandeler

Qbs 1.13 released

Published Thursday April 18th, 2019
32 Comments on Qbs 1.13 released
Posted in Build system, Dev Loop | Tags:

We are happy to announce version 1.13.0 of the Qbs build tool. This is the last version to be released under the auspices of the Qt Company, but certainly not the least.


Transparent pkg-config support

Qbs projects can now make use of pkg-config modules. Syntax-wise, the same dependency mechanism as for Qbs’ own modules is used. For instance, on a typical Linux machine with an OpenSSL development package installed, the following is enough to let a Qbs project build against it:

Depends { name: "openssl" }

Internally, this functionality is implemented on top of module providers, a powerful new feature that allows creating Qbs modules on demand.

Automatic Qt detection

Projects with a Qt dependency now set up the required Qt-specific modules (such as Qt.core) automatically at build time, using either the PATH environment variable or the moduleProviders.Qt.qmakeFilePaths property. It is therefore no longer strictly necessary to create a profile using the setup-qt command. Behind the scenes, this feature is also implemented using module providers.

Job Pools

The global limit for the number of concurrently running jobs does not make sense for all types of commands. For instance, linkers are typically I/O-bound and take up a lot of memory, so it often makes sense not to parallelize them as much as compilers. Here’s how job-specific limits are set on the command line:

$ qbs --job-limits linker:2,compiler:8

These limits can also be provided via preferences and in project files. The details are explained here.

What else is new?

Language Improvements

Rules are no longer required to specify output artifacts. As a result, rules whose main purpose is in their “side effect” will look more natural now, as they don’t need to declare a dummy output file anymore.

It is no longer necessary to start each project file with an “import qbs” line.

The Application, DynamicLibrary and StaticLibrary items have new properties install and installDir for more convenient installation of target binaries.

We introduced Process.atEnd() and FileInfo.canonicalPath().

C/C++ Support

GNU linker scripts are now scanned recursively to catch changes to included linker scripts. Thanks to Ola Røer Thorsen for this contribution!

The new cpp.linkerVariant property allows to force the use of, ld.bfd or lld for linking.

Qt Support

We introduced the new property Qt.core.enableBigResources for the creation of “big” Qt resources.

Static builds now pull in the default set of plugins as specified by Qt, and the user can specify the set of plugins by type.

Android Support

The AndroidApk item has been deprecated. Instead, a normal Application item can and should be used now.

Building Qt apps is properly supported now. Some small changes to Qt’s androiddeployqt tool were necessary to achieve this, so you need at least Qt 5.12.

Autotest Support

There is an autotest module now, which you can use to specify arguments and working directory per test.

Various things

We introduced the texttemplate module, a facility similar to qmake’s QMAKE_SUBSTITUTES feature.

We added basic support for Google Protocol Buffers (for C++ and Objective-C). Thanks to Ivan Komissarov for this contribution!

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, and on the mailing list. The documentation and wiki are also good 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, Fedora, and Arch Linux.

Qbs 1.13.0 is also included in Qt Creator 4.9.0, which was released earlier this week.

So, what now?

Preparations for handing over the project to the community are ongoing. Stay tuned for further announcements.

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

Posted in Build system, Dev Loop | Tags:


Pier Luigi Fiorini says:

Impressive features list.
Another excellent release.

Kai Dohmen says:

I Love the new release 😀 I added protobuf Support by myself 2 month ago and wondered when it would be supported “nativly”.
Hope that the rumors that “Qbs is dead” wont last long and more projects start using Qbs

PS: sorry for the wrong bug report…

Ivan says:

Feedback for the Protobuf support is welcome, I didn’t have enough time to finish the module properly (e.g. support pkg-config, other languages) and I dind’t really use it in any qbs project, so something can be clearly missing.

Erteple says:

You killed a great product.

Ivan says:

Great news, thanks!

Vladimir says:

Some questions about QBS future support in Qt Project:
1. Will qt project retain repo for QBS? CI builds?
2. If not , who/where new repo will be? Bugtracker QBS will be closed?
3. If thirdparty team (KDAB/someone else) will host and maintain QBS, will Qt Creator use updated module?

Richard says:

Good questions. May I invite you to join the qbs mailing list and discuss these topics there?

Letrab says:

Happy to hear there is still confidence QBS will keep existing!

Thank for your work!
The texttemplate addition is great, just about starting work where this is very welcome!

Alexey says:

What about iOs support?

Eli says:

This came unexpected! A big thank you to all the contributors!

Still there is a elephant in the room: What build system does a developer choose in 2019 when he wants to create an qt app. Qmake, cmake, qbs, meson? All my apps use currently qmake. I tried qbs and it was really promising. Then yesterday I tried cmake and oh well….

By the mixed signal of the qt company “Deprecation of Qbs” it is even harder to convince developers to go full ahead and port theirs apps to this build system. I guess the only way I could see qbs to survive is to have support for cmake packages. So one could use the handy vcpkg package manager with qbs…

When the qt company does no longer has interest in qbs then they should move the project to gitlab or github. Make a website for people to find (no qt programmer I know even nows that qbs exsist!) and show the people its potential!

@Eli: Recommendation is to use qmake or CMake. We are aware that currently CMake is not as polished as it could be. It works and there are many Qt users already using CMake. We are also working to improve the experience of using CMake in Qt application and device development.

Zehudev says:

Problem is that CMake is not build system it is just generator.

It would be good to have posibility to add file/dir/unittest, compile one file or compile subproject, add library etc. But it is not possible because of CMake! Apparently out of scope.

In QBS/QMake it was possible, now for CMake it is out of scope?

CMake has itself a lot of issues concerning Qt itself. Together with issues QtCreator it is really bad.

problems with:
– translations
– recompiling/checking _moc files,
– often need to delete CMakeCache.txt when creating/modifying project ( severity depends on how good CMakeFiles.txt is configured )
– duplicating targets when changing project ( solution close QtCreator delete .user file and reopen / it has nothing to do with CMake so deleting cmakecache wont help )
– and of course not possible to edit project in any way since is it Out of Scope

Basically with CMake with QtCreator does not work together well and apparently wont be any time soon, because a lot of thing is out of scope.

In Java IDEs it is possible to click on function and create Unitest. On the other hand with QtCreator in future version with CMake you wont be able to even add a single file into project -> I do not think it is good way to go.

By the way, what is correct way to add single file into CMake project using QtCreator 4.9?
Let’s say I start with primitive CMake project with your template: C++ using CMake:
1) Then I Create new file choose to add to just created project and ….
2) ….Nothing

This is the way you want to go?

Do you really think this is correct way to do things?

Szyk Cech says:

First of all Cmake has some advantages:
* You can define directory where you want o install your target (/usr or /usr/local) and it properly default to the /usr/local – in qmake you can define you want install by default in /usr/local but you cant change it – you can only define prefix to this default dir
* It can generate and recognise *Config.cmake files which simplify library usage
* It is friendly to the make and autotools by easy generating *.pc files
* It shows progres when compile
* It allow define multiple targets and include other CMakeLists.txt without any problems (qmake require split all of these in to separate files)

When you talk about file addition and rename. I don’t think it is big deal. Why? Lets see the facts: In Qt Creator we have listed all files in the cmake project. Right? So I think we have absolute path to each file. If so there is only matter of few lines of code which must be added to Qt Creator sources to handle these two cases (add and rename):
1) in order to add file: get directory of existing selected file (this selection can be required) and ask user for accept this dir (and type new file name). Then run cmake for this project and reload configuration (ideally with selection new file).
2) in order to rename: get full path to file, rename it in the source tree, save to disk and reload cmake project.

It is piece of cake if we compare it to whole Qt Creator development.

Zehudev says:

The only advantage over qmake for me was that cmake can automatically define multiple targets, which is good to automatically scan e.g. tst_*.cpp files and make them unittests.
But in QBS it was also possible and it was really nice to work with that build system. Option was QBS or CMake not QMake

To that “adding files” You think exactly as comments of this issue:
Support adding files to cmake project: ( closed – resolution out of scope )
Reason: This bug report is out of scope for as long as creator needs to parse CMakeLists.txt

It looks like they wont do that! No matter how easy you, me or anybody else think it is.
I think reason is that QtCreator works with generated files not with source files and there is not easy transformation with that, they do not want to do that.

HGH says:

How do you plan to actually polish CMake? It does need a new DSL (object oriented, debuggable, supported by IDE) . I see so many scenarios where a complete scripting environment would be beneficial not just declarative functionality.

Sys says:

Great news, brave people!

Marcel Charlebois says:

200 comments under “Deprecation of Qbs” and zero here after 3 days since this was posted… I guess everybody realizes that Qbs is already dead.

Richard says:

Blog comments require moderation, but there were easter holidays in Germany.

Borgar Øvsthus says:

Great news! Thanks to everyone involved!

John says:

Big thank to all people behind QBS.

Szyk Cech says:

@Christian Kandeler – what will you do now? Will you left Or will you switch to other tasks?

Christian Kandeler Christian Kandeler says:

That’s somewhat off topic, but I’m still with the Qt Company, working on Qt Creator.

fbucek says:

Any chance to move QBS to GitHub/GitLab ( I guess Qt also uses GitLab for some projects ) from Gerrit which is really not good for community contributions.
I think more people would contribute even to Qt if it was possible using GitHub/GitLab.

Christian Kandeler Christian Kandeler says:

This is one of the topics that are to be considered as part of the community handover process.

@fbucek: Not directly related to this, but in general what do you see as problems with the Gerrit workflow that prevents contributions? For example, peer reviews, approvals and passing CI tests are steps needed to ensure good quality of the code. These are undeniably also items that make contributions more challenging.

fbucek says:

My opinion:
Nothing prevent contribution but It is much much harder to use then GitHub/GitLab for the first commit. But without first commit you wont get next.

Good thing of gerrit is that main repository does not get polluted with many branches, merge-requests etc.

But: For newcomer it is rally hard to setup Gerrit and to work with that.

Basically it is many pages to read to evaluate what is necessary what is not. Gerrit UI is not very good and more over you are using version release in 2012 i guess.

GitLab/GitHub and many other are using Git and its abilities and basically workflow is identical, just UI is different.

Gerrit on the other hand use Git mainly as repo only. Merging to masters are done out of Git I guess. So work is completely different. Gerrit has specific commands, you cannot switch to anybody else branch because it does not work on branches or commits but “patches”. When you want to continue there is no branch to switch just patch to checkout as detached head. Gerrit track changes based on ID in commit not on Git dependancy tree. From help it is not clear what is important what is not and how it works.

Try ask anybody who is not familiar with Gerrit to contribute to latest version of Qt ( do not give him any advice )

I know that after first commit I would do second commit in seconds but first took hours or even days ( I was not sure about something so I asked on #irc where I got answer next day )

Try once in a time to ask somebody unfamiliar to Qt to: contribute, or install Qt and run on Linux, macOS, Windows or even to deploy application.

Jochen Ulrich says:

The Chocolatey package is not updated yet (it’s still 1.12.1, see
Will the package be updated sometime soon?

Richard says:


Would you be interested?

Jörg Bornemann Jörg Bornemann says:

I’ve updated the chocolatey package now.

Denis Shienkov says:

In this 1.13 release also are improved the bare-metal stuff. There are added support for an additional toolchains, as IAR and KEIL (for three architectures: ARM, AVR, MCS51).

Until, there are no integration with QtC 4.9 (need to create a ‘custom’ toolchains in QtC). But in next release the QtC (> 4.9) will contains the new KEIL, IAR and SDCC toolchains too (the QBS also will contains a new SDCC toolchain). So, it is possible to build the bare-metal stuff from the QtC using QBS without any problems.

PS: Of course, it is an ‘experimental’ first option and may contains an errors. 🙂

Thorbjørn Lindeijer says:

Awesome release! I’ll never understand the reasoning of the Qt Company on stopping this one. I expect it will remain my favorite build system for a long time to come.

koval says:

Qbs is so much better than other build systems. Unlike qmake it does not need gmake/nmake/jom/etc. and unlike cmake it allows to write functions that return values instead of procedures (ironically called functions) that take variable names and operate on them.
I really like that things like code generators can be coded directly as JavaScriptCommand so there is no need to find sed/awk/perl for windows. This is truely portable build system and I really love that you can finally set the limit on simultaneous linker jobs. That helps a lot with builds under VirtualBox with ridiculous size of 8GB RAM (people have more memory on their mobiles these days…)

I wonder what is going to be with the deprecation status of qtscript which qbs relies on. Are there plans to port to qtdeclarative or maybe qtdeclarative will get features like addFunction to make porting a mere search-and-replace action?

Commenting closed.

Get started today with Qt Download now