qbs 1.1.0 released

Published Wednesday November 6th, 2013 | by

It’s been a while since qbs 1.0.0 has come out, and things have been adding up – time for qbs 1.1.0!

What’s newsworthy?

  • Projects can now be nested, making it very easy to embed a stand-alone project into another one.
  • Change tracking has improved a lot: We now catch more factors that (may) require parts of a project to be rebuilt, and on the other hand we also do less unnecessary re-builds. For future releases, we aim at more improvements in this area.
  • Due to more thorough checks for mistakes such as syntax errors in project files or missing information in profiles, we are able to provide more helpful error messages, which should make life considerably easier for users.
  • The API provides more information to IDEs, which enables better qbs project support in the upcoming Qt Creator 3.0.
  • A lot of documentation has been added, particularly for the project file language. This area was seriously lacking in the first release.
  • There is now a GUI application for editing profiles and other settings.

Of course, there have also been countless bugfixes and smaller improvements. In particular, we would like to thank Jake Petroules for his continuous efforts in making and keeping the OSX platform well-supported.

Where do I get it?

Source packages and a binary package for Windows can be found here.
Commercial customers can download the enterprise version of qbs from the Customer Portal.

Other resources

Wiki: http://qt-project.org/wiki/qbs
Documentation: http://doc-snapshot.qt-project.org/qbs
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, Compilers, Releases

19 comments to qbs 1.1.0 released

BogDan says:

Congrats (Y) !

J says:

QBS is the best build system I’ve ever seen. I can compile for Android, iOS, BlackBerry 10, Linux, MacOSX, and Windows at the same time! I’d really like to see a Visual Studio plug in to use QBS files as sln files, but that’s just to convince my colleagues; I use Qt Creator. Thank you very much for this excellent build system!

Cross-platform developer says:

Have you tried CMake? IMHO it’s even better:
- Finders (FindQt5.cmake, etc) make very easy to work with third-party dependencies
- CPacks makes trivial to generate installers for any platform
- Cross-compilation
- Platform-definition files (a must for for embedded targets)
- ExternalProject makes it easy to create a superbuild that downloads and builds every dependency
- And much more

Oh, and the language makes sense. I’m sick of all those brackets and semicolons in qbs. JSON is fine for computers but we are humans!

J says:

Yes. CMake is nice. QBS is better. I came from CMake, and it’s so imperative that it’s imposible to analyse, which means your IDE will very likely never be able to edit it. It also depends on external tools to do the actual dependency checking and compiler invocation, so it’s harder to make builds faster. Cross-compiling is much more tedious in CMake (I’ve done it, and I’ll never do it again, if I can help it) due to all of the special cases platforms like Android required one to work around imperatively.

QBS is designed to be edited by an IDE because it’s based on QML. It invokes the compiler directly, and it has the capability to invoke several different cross compilers at the same time to build all of your platforms at once using all of the processors in your build machine. It also will do the “right thing” to make your app fully cross platform when you declare an application instead of requiring you to work around it (Android .so files and Java stub wrappers, etc.).

elemental says:

I switched a big project QBS. The project uses couple of toolchains at the same time and it works amazing. The productivity, flexibility and performance is way better than with other build systems. Thank you very much for working on this!

Slartibart says:

Nice to see the new build system getting up to speed, but at 14MB compressed it’s silly large. And a huge part of that is because of (mostly unused) maps in the ICU library (uncompressed 18-19MB). Please consider making a lean configuration :P

http://userguide.icu-project.org/icufaq#TOC-How-can-I-reduce-the-size-of-the-ICU-data-library-

Jörg Bornemann says:

You’re right, the binary package is much too fat. Mostly due to the qbs-config-ui tool, which is based on QtWidget. But thanks for the ICU size reduction hint! :)

fonzi337 says:

QBS is looking very promising! :)

One question: how mature would you say this latest release is for use in a production environment? We currently use qmake but would love to switch our SUBDIRS projects to QBS sooner rather than later (baring any show-stopping issues/missing functionality).

Rene Jensen says:

I took the chance and switched my qmake subdirs project to QBS on a production application for Windows desktop. Software used internally in a fairly large company.
I have had few problems – an initially missing axwidget module for COM objects, and the integration between QtCreator and QBS haven’t matured that much (e.g. you have to create new files using Creators menus – can’t right click in the project explorer).

But compared to the insane speed increase in application building/launching, those are minor problems at worst. QBS is instantaneous in most regards and a real productivity booster (this is Windows specific, because Windows suffers from slow file stat’ing).

It is worth trying to figure it out. Even more so if you are already familiar with QML (I have not once used javascript yet).
Also make use of the quick reference linked in the documentation (http://qt-project.org/wiki/Qbs-Quick-Reference).

Rene Jensen says:

The only thing I DO miss is a recursive version of the Group element which preserves folder structure during installation.
Right now I have one group per subfolder:
Group { qbs.install: true; qbs.installDir: “media” ; files: “*”; prefix: “media/” }
Group { qbs.install: true; qbs.installDir: “media/qml” ; files: “*”; prefix: “media/qml/” }
Group { qbs.install: true; qbs.installDir: “media/qml/extras” ; files: “*”; prefix: “media/qml/extras/” }
Group { qbs.install: true; qbs.installDir: “media/qml/images” ; files: “*”; prefix: “media/qml/images/” }
Group { qbs.install: true; qbs.installDir: “media/qml/resources” ; files: “*”; prefix: “media/qml/resources/” }

… etc…

But I’m sure that it is only a matter of time before something will be available. (No, the “recursive” attribute doesn’t work with installation).

Christian Kandeler says:

If you don’t need any of the specific files in the directory to be known to qbs, you can just make a group with the top-level directory as the only file.

Rene Jensen says:

Yes. But I *do* need them to be know to QBS, because I need them to be known to QtCreator. The QML files needs to show up in the project explorer in their proper subfolders.

… And adding to the list of benefits of QBS: Finally we can get rid of the annoying split in project explorer between headers, sources, other files etc.

Rene Jensen says:

Quick addition…
In regard to the question of production readiness, I have a few times been in a nasty scenario (mostly predating Qt 5.1 SDK) where QBS seemed to crash or something when it could not figure out include dependencies. On Windows, QBS didn’t properly report errors to QtCreator (oddly error printing turned out to work fine on Linux). The result was that if I renamed a header file, then occasionally QBS could not parse anything. It didn’t report any errors and the project explorer in creator went blank.

I haven’t tried QBS 1.1 yet. It sounds like they improved error handling.

Still, it’s a risk I am willing to take. All problems have been fixable so far.

fonzi337 says:

Thank you Rene for sharing your experience. It’s encouraging to know that someone else has tried it with good success in a production environment. I’ll give it a shot and see how it goes.

chezgi says:

thanks for best build system ever.
but:
its configuration for android is incomplete.
qtcreator exports to qbs with some missing data.
qtConfig and gcc options are missing. therefore it
dos’nt compile for android.

Andreas says:

Looking very promising! Guess I need to try this very soon.

How suited is qbs for non-Qt projects? How intertwined is it with the Qt libraries? To compile a qbs project, is the entire Qt suite required?

I’ve been considering general purpose build system that I can use for both my Qt projects and generic C++ projects. Is qbs a candidate?

Christian Kandeler says:

It’s a general-purpose build tool. Special support for particular frameworks can be provided via modules. Qt is one such framework, for which we happen to ship a module, as Qt support is important for us. The same could be done for other frameworks.
Since qbs is implemented using Qt, it requires some Qt libraries, namely Qt Core and Qt Script (strictly required) and Qt Widgets (for the graphical profile editing tool only; disabling it currently needs manual fiddling with project files).
I hope this answers your questions.

J says:

I personally use it for all new projects, and I’ve converted all of my non-work projects to QBS.

Let me just say this: I have a situation that requires me to compile code to many different platforms, and it has quite a few dependancies. I’ve converted CMake, Autoconf, qmake, and raw make files from the dependancies to QBS so that I could debug my projects and the dependancies on multiple platforms.

These dependancies required some preprocessor definitions while they were building, and -different- preprocessor definitions when projects that depended on them were being compiled (that used the first project’s headers). QBS has a way of specifying dependancies, AND a way to specify configuration changes to projects that depend on the project that you’re currently defining IN A CONCISE WAY that works across all platforms.

If you haven’t tried QBS, you need to try it. I have never spent so little time on build system files with full confidence in their correctness.

Ionut Dediu says:

I haven’t tried QBS but if it’s as good as it sounds it could be a back door to spread the word about Qt; devs could use it to build their own non Qt projects, be amazed by QBS, and start looking into migrating the src to Qt as well :)

Commenting closed.