qbs 1.2.0 released

Published Monday May 5th, 2014 | by

We’re happy to announce the release of qbs 1.2.0! Qbs, or Qt Build Suite, is a general cross-platform build tool with a QMLish project description language. More information can be found on its documentation page.

This version fixes a lot of bugs and adds a heap of features that you requested. The qbs plugin of Qt Creator 3.1.0 is already based on qbs 1.2.0.

Qbs now supports rules with a flexible number of outputs.  For example, you may write an IDL file containing the descriptions of several C++ interfaces. An interface compiler generates a number of header files. The generated header files are automatically taken into account as potential dependencies. Changing the content of the IDL file is fully tracked, leading to a rebuild of the affected parts of your project. This is of course not special-cased for the IDL use case. This feature is useful for any kind of code generator (e.g. flex/bison) where you can specify in the source what kind of files are generated and how these files are named.

Another use case for those dynamic rules is moc. We’ve adapted the moc handling of qbs to use dynamic rules and got rid off the lengthy “automoc” scanning phase before every build.

Other changes worth mentioning:

  • Incremental builds got more robust.
  • Thanks to Jake Petroules we now have modules for creating Windows installers based on NSIS or WiX (MSI).
  • JavaScript files can load qbs extensions and other JavaScript files, similar to Qt.include in QML.
  • The memory footprint has been reduced significantly.

Where do I get it?

Source packages and a binary package for Windows can be found here.
Enterprise customers can download the enterprise version of qbs from Qt Account.

Other resources

Wiki: http://qt-project.org/wiki/qbs
Documentation: http://qt-project.org/doc/qbs-1.2/index.html
Bug tracker: https://bugreports.qt-project.org/browse/QBS
Mailing list: http://lists.qt-project.org/mailman/listinfo/qbs

Did you like this? Share it:

Posted in Build system

24 comments to qbs 1.2.0 released

HGH says:

When will this replace qmake by default?

One Qmaker says:

Not very soon as really many projects still use and depend on qmake.

But you can use qbs by default if you like, I hope it doesn’t disturb you too much if someone prefers qmake.

J says:

Sounds great! I’ll have to try out the new installer generators.

chezgi says:

thanks for this great work.
when it supports android deployment?
qbs is powerfull for multi platform building and android platform is missing.

loaden says:

How about Android support, when it is coming?

Drew says:

The documentation doesn’t give background or justification for the project. We already have qmake. What does qbs provide that qmake can not handle? What is the point of qbs? It would be handy to have that documented.

Jörg Bornemann says:

@HGH: It’s your personal choice to use qmake, qbs or any other build tool for your projects.

@chezgi @loaden: Android support (including package creation) is planned for 1.3.

@Drew: please see http://blog.qt.digia.com/blog/2012/02/15/introducing-qbs/

Will says:

@Jorg, is there a plan for Qt Creator to make QBS projects instead of QMake projects by default, for example? If so, when might that happen? I’m very excited about QBS, and I am likely to eventually move an internal large-ish project over to it but probably not until it works “out of the box” without having to install it separate from the normal Qt SDK install.

Anyhow, congrats on a new release of an exciting project. I am looking forward to digging into the MSI generation stuff. Maybe a future blog post just on installers/packaging using QBS?

Jörg Bornemann says:

The project wizards in Qt Creator are unfortunately a bit too closely tied to qmake at the moment and we’re reluctant to copy, paste and adjust them for qbs. There are ideas floating around since quite a while to refactor the project wizards to support other build tools than qmake. But when this will be tackled, I cannot say.

Kevin Puetz says:

Any plans for Visual Studio integration? I’m aware that generating .vcxproj files as qmake does is in the “not going to happen” category due to the fact that qbs actually does the build itself. And frankly, not having nmake vs. jom. vs. mingw32-make vs. msbuild discrepencies is a major advantage :-)

But it would be nice (i.e. a lot easier to sell a qmake->qbs migration) if it was still possible to work within the VS IDE for those who prefer it.

Visual studio has the concept of a “Makefile project” where it actually just calls a command line (not necessarily nmake) to do the build. The contents of such a project are just the relevant command-lines/executable names so the build/run/debug buttons can still integrate, and (optionally, but desireable) a list of source files just to feed the editor’s project tree. If needed, it can also provide preprocessor definitions, include search paths, and prefix include files like for intellisense to use.

Jörg Bornemann says:

That’s right. We definitely need a story for VS users, but we don’t want to create another vcxproj generator. Your suggestion to create a Makefile project looks like the way to go.

jys0224 says:

How can I add serial port sub module ?

Jörg Bornemann says:

If your Qt build contains the serial port module, then it should be picked up by qbs-setup-qt and then be available as Qt.serialport. If that doesn’t work for you, please create a bug report.

Roland Wolf says:

In a cmake project I do not have to remember that anything was changed in CMakeLists.txt. The generated make file will simply call cmake again if needed. Running cmake explicityl is needed only once. In qbs and qmake projects I need to call qbs/qmake whenever the build script changed. In real live this leads to lots of error hunting which is only due to a forgotten manual call of qbs/qmake. Did I miss something or is this a missing feature of qbs?

Jörg Bornemann says:

Yes, qmake has this problem. But one important feature of qbs is that it keeps track of changes in the project file. If you encounter problems with incremental builds, that’s most likely a bug.

Filip Piechocki says:

@Roland: with qbs it is clear you have to call qbs whenever you want to build your project, as qbs actually builds the project (so instead od qmake && make, you just call qbs). I often call qmake just in case when I am compiling from command line but AFAIR changing .pro file where you have your Makefile already generated and then calling make calls the qmake – or am I wrong?

Alex says:

qbs itself depends on Qt, so it can be used only on platforms which is supported by Qt (Win, Linux, Mac), is it correct?

Jörg Bornemann says:

Yes. Add *BSD to your list.
What platform do you have in mind that’s unsupported?

Alex says:

Solaris would be nice :) we have to build our product for Solaris time to time. In theory it should be possible to cross-build, but we do not have such experience right now, using only native build. If Qbs will support native build on all our target platform it will be a signigicant argument for our team vs cmake.
Does Digia provide biniry only for Win?

Jörg Bornemann says:

It might be possible to keep those parts of Qt working on Solaris that are needed for qbs.
Currently, only Windows binaries are provided. This should definitely change.

Alex says:

Any preferences of being “Enterprise customers”? Is it possible for “Enterprise customers” to request RedHat 5/Solaris build of Qbs?

Jörg Bornemann says:

RedHat shouldn’t be a problem. I cannot say how much effort it would be to create a Solaris build.

Pavel says:

I have mixed feelings when reading “incremental builds got more robust”. This problem has been solved by make decades ago, and most problems with it result from improper use (e.g. qmake’s DEPENDPATH “feature”, or the above-mentioned fact that qmake does not include the project file in the target’s dependencies).

Jörg Bornemann says:

Adding the project file to the target’s dependencies is clearly not enough.
Consider a change of properties (C++ defines or such) for a certain group of source files. You want these, and only these, files automatically recompiled.
When writing that “incremental builds got more robust” I was referring to the improvements in tracking property changes and changes of inter-product dependencies.

Commenting closed.