Jake Petroules

Qbs 1.8 released

Published Monday May 29th, 2017
46 Comments on Qbs 1.8 released
Posted in Announcements, Biz Circuit & Dev Loop, Build system, Releases

Qbs (pronounced “Cubes”) is The Qt Company’s latest build tool, which is planned to be the replacement for qmake in the Qt 6 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, we’re pleased to announce the release of Qbs 1.8! This is primarily a stability-focused release which paves the way for some powerful new features coming in a few months with 1.9.

What’s new?

In addition to the usual bug fixes and performance enhancements, this release provides the following new features:

New Platforms and Toolchains

Qbs now has initial support for building applications for the QNX real-time operating system. We support several versions of the official QNX SDK: SDP 6.5, SDP 6.6, and the recently released SDP 7.0 with support for development on macOS. We may also extend support to additional toolchains in the future, like Intel ICC.

There is also basic support for building FreeBSD applications. While it has always been possible to build for FreeBSD, it is now a recognized target and therefore projects targeting that platform build without any additional environment configuration.

Android Support

Single-architecture Android builds are now handled more gracefully. This means Qbs will be usable in Qt Creator when building for Android, and dependencies on Qt modules should work too. This moves us closer to functional Android support, although there are still many tasks left to do, including support for Clang/LLVM from the Android NDK.

Language Improvements

A new syntax for accessing module properties in JavaScript extensions has been introduced. You can now use the syntax product.modulename.propertyname to access a module property of a product or artifact, so that you get consistent property access syntax between Qbs files and JavaScript files. For example, product.moduleProperty("cpp", "compilerFlags") should now be written as product.cpp.compilerFlags. For module authors, note that the module object might be undefined if the module is not loaded in the given product’s context, so you should check that it is a truthy value before using it (for example: !!product.cpp). Note that the old moduleProperty() function will still be available but its use is discouraged.

Read-only properties are now supported. Declaring a property with the readonly modifier will now cause an error to be emitted if an attempt is made to set a value on it.

Probe items are now allowed within Project items, which should allow more logical project structures for Probes that really aren’t dependent on a particular product’s context.

The loadFile() and loadExtension() function have been replaced by require() and will be deprecated in a future release.

Profiles

Qbs can now be run without a profile. This is a small but enabling change which follows from our new strategy that favors automatic detection and Probes over the use of pre-created profiles in order to push an “it just works” experience. This change makes it easier for new users to get started with Qbs, while also making development environment maintenance easier by reducing reliance on external data that requires manual setup and is likely to become outdated over time. You can of course continue to use profiles just like before, however invoking ‘qbs’ from the command line will now automatically build for the current host platform using the best available toolchain and settings unless a default profile is set. You can also explicitly use the “null” profile by specifying profile:none on the command line.

Currently this has no effect on how projects are built in Qt Creator; Qbs projects in the IDE always use an automatically generated profile which sets a minimal set of properties corresponding to the selected kit.

Other new features

  • Added a new qbs-create-project tool which can help to automatically generate qbs project files from an arbitrary directory structure. This can be a useful starting point when migrating from other build tools such as qmake or CMake.
  • The means to easily combine source files for the C language family in order to support “amalgamation builds”.
  • qbs-setup-toolchains adds support for Visual C++ Build Tools.
  • Better line and column information in error reporting.
  • PkgConfigProbe now provides a higher level API by parsing the raw compiler and linker flags output from pkg-config. There are new properties individually listing the preprocessor defines, include paths, compiler flags, and so on.
  • Fixes to change tracking and general handling of manifests in the Java module.
  • It should now be possible to build qbs itself statically, as the scanner plugins have been fixed to be compatible with static builds.

That’s all for now. The Xcode generator was unfortunately delayed again and thefore is not present in 1.8, but 1.9 will be quite a monumental release bringing some very significant new features around multiplexing and dependency handling. Stay tuned!

Breaking Changes

There are a few breaking changes of note in this release:

First, the cpp.linkerFlags property no longer accepts pre-escaped values. That is, you should not escape linker flags passed to the cpp.linkerFlags property with the -Wl, or -Xlinker escape sequences, as Qbs will automatically apply them based on whether the linker in use is the compiler driver (like clang++ or g++) or the system linker (like ld). This has generated a warning for the past couple of releases and we encourage you to migrate your build scripts if you haven’t already, as using -Wl, or -Xlinker in cpp.linkerFlags will now lead to a double-escape and a linker error.

Second, all files that are part of a bundle on Apple platforms like macOS and iOS are now tagged with “bundle.content”. If you want to install the files that constitute a bundle, this is the one and only tag that your installation Group’s fileTagsFilter should reference. Previous methods of installing bundles based on the file tags of the individual files that constitute them are not guaranteed to work.

Last, the base directory for source files has changed from the product source directory to the parent directory of the file where the files are listed. The old behavior was unintuitive and usually not what users want when groups are pulled in from other files such as modules.

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.

Qbs 1.8 is also included in Qt Creator 4.3, which was released earlier this week.

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

46 comments

Alexander Orlov says:

Why not using Gradle, a popular & powerful bulid tool that many people already know? Just because it’s based on Java…?

Using Gradle would attract many new developers to the Qt Toolkit. Especially when Qt finally targets WebAssembly where the language does not matter anyway.

Jake Petroules Jake Petroules says:

As I mentioned in my other comment, we will publish a post in the coming months that goes into more detail about why existing solutions like CMake and Gradle are not the best options for us.

Gradle’s Java roots are one reason it is not suitable, because we need to enable Linux distributions to build qbs and Qt with the most minimal dependency set as possible. Consider also if a JVM implementation itself wanted to use qbs as its build system. By aiming to require only a C++ compiler to build qbs, we provide the widest range of possible use cases for qbs — we want people to use it to build any number of projects, even those which aren’t necessarily using Qt.

I also disagree that using Gradle would attract many new developers. The “ecosystem argument” some people use only really applies to CMake.

Tim says:

Because Gradle is awful and insanely slow.

Rune Karlsen says:

You could add that Gradle and Android “license” tracking during builds is standard Google intrusive practice and a security concern for anyone.

Alexander Orlov says:

I don’t know what you mean with ‘“license” tracking‘ but Gradle is not related to Android nor Google whatsoever.

Alexander Orlov says:

If you have used Gradle just once, you wold know that this is completely untrue. Gradle supports parallel, incremental, and daemon-backed compilation. A project that contains hunderts of classes is compiled in a fraction of a second thanks to incremental compilation.

Jake Petroules Jake Petroules says:

Gradle’s performance has improved a lot over the years, but he isn’t wrong that it can be quite slow. I remember incremental builds taking up to half a minute even for a relatively small project as recently as mid 2015. Consider that “hundreds” of files is also a very small project; there are projects which have thousands or tends of thousands of files.

Rune Karlsen says:

Downloading dependencies are slow, but needed for some clean builds… not that this is any of Gradle’s fault and being able to restrict builds with Gradle to only use disk-cached dependencies is a great and important feature of Gradle. Plugins and build-variants definitely add to build-times though.

Try building something Android without the license keys and it fails miserably. That is something enabled through the Gradle Android-plugin, which is not directly part of Gradle itself. Otherwise I think Gradle is nice, although Groovy can get to be a bit much after too much Jenkins Scripted Pipeline and their CPS…

A lot of “magic” is done in Android Studio looking through the build.gradle files and checking updates, while the dependencies in build.gradle needs a bit of sed-processing to be able to make properly cached/versioned enviroments for fully binary-reproducible builds. The scripted dependency-specification approach in Gradle is both powerful and difficult to tackle without going through all the motions of actually building the software to produce the needed environment. In that way the Npm/Yarn approach with declarative and lockable/pinnable dependencies are much easier to deal with.

Hopefully Qbs will be able to deal with these things in a cherry-picking way. 🙂

tr3w says:

I really like the idea and the syntax of qbs, but unfortunately I cannot use it in my daily work.
My main problem is with creating custom modules: I need to create an extra folders, add it to qbsSearchPaths, etc.
I don’t want to do all that. I just want to create a new file for the module, import it, and done.

I also think if you really serious about qbs as a general purpose build tool, what is really missing is a repository of predefined modules, (like all that Find*.cmake stuff coming with cmake). So I don’t even need to create my custom modules most of the time…

Jake Petroules Jake Petroules says:

I’m not clear on why you can’t use qbs for your daily work as a result of the directory structure it requires for importing modules into your project. It’s quite straightforward already, and in the future we can perhaps think about adding shortcuts for creating new modules directly within the Qt Creator UI. Is there some particular issue you’re running into?

Regarding a common repository of predefined modules similar to CMake’s repository of Find* modules, this is something we are actively working on, so stay tuned.

tr3w says:

Sorry if I wasn’t clear, I should have list my issues in reverse order.
I can’t use qbs in my daily work, because we have a lot of dependencies, and I don’t want to write all the modules by hand.
A repository of modules can solve that.

But I don’t expect to have all my required modules in that repository, but for one or two additional modules this whole creating multiple directories and setting up a path looks kind of overkill.
I would really love something as simple as in normal QML: I can create my new items in any folder, I just need to import it, and I’m done.

Christian Kandeler Christian Kandeler says:

If you only want to quickly write a module for use in one particular project, you can simply use a Product and put all the “module stuff” in its Export item.
However, in any non-trivial project, you should have a central place for storing your modules and base items anyway, so I don’t really see the hassle: Create the directories once, set the search path once in your top-level project file, done.

Florian says:

Why do we need another build system?
I think Qt should either stick to qmake (as strange/old as it is, but used by many people)
or switch to CMake which has a big eco system, like KDE did.
Building another build system only costs resources that you could spend on other things.
Sorry for being so harsh.

Jake Petroules Jake Petroules says:

Although there are widely used competitors like CMake, we feel that we can deliver a superior developer experience and greater functionality. It can be difficult to understand the value of a new product without using it firsthand and understanding the value it provides, which is why in the coming months we plan to publish another post that goes into detail about why qbs is being developed and why alternatives like CMake or Gradle were found to be insufficient for our needs. For now, I’ll say that it boils down to better maintainability and extensibility for us, and better performance and a richer feature set for our customers and users.

We feel that the resources we are spending on this new build tool are worth the savings we will gain from having to deal with the alternatives like qmake or CMake, and the ease of use and richness of functionality that our customers and users will gain, allowing them to focus on building their applications rather than messing around with build tools.

Just because something is well established doesn’t necessarily mean you shouldn’t try to do better. Remember, Nokia held over 50% of the world’s smartphone market just 10 years ago… until Apple came along with something better.

Florian says:

Yes, I am using Cmake, Qmake, scons, distutils, gnumake, bjam, you name it… because we integrate many ThirdParty projects in our build system (which is using Python, today we would use Jenkins), we need to be able to build various projects cross platform… And I feel that there is definitely a trend towards CMake. Which is why I don’t think that we need yet another build tool done. But ok, maybe you are revolutionizing the build system market, lets see in 3-5 years if you overtook Cmake.

Tim says:

Have you actually used CMake? It’s kind of insane. It’s also fairly slow.

QBS is *much* faster, reasonably sane (though the `Properties` thing is still weird) and integrates well with IDEs.

Meson is another sane modern build system and is probably the best alternative to QBS but it’s also not that mature either so we’ll have to see which wins.

jona yang says:

Please add support for ninja generator. Or you guys just adding unnecessary burden for end user. Gnu make is very slow even with -j flag.

Jake Petroules Jake Petroules says:

I believe you’re misunderstanding how Qbs works. Qbs does not rely on Makefiles or GNU make in any way, so there is no need for a Ninja generator. Qbs handles the entire build process by itself and is already as fast or faster than Ninja.

Vladimir Smirnov says:

Jake, have you tried to compare qbs and ninja by speed? I don’t think that qbs could be faster, ninja doesn’t use configuration phase. I’ve tested on my project – cmake+ ninja incremental builds is faster that qbs incremental builds (both using wildcards for file matching).
Moreover, ninja perfectly integrates with distributed build systems – taking Xoreax solutions, or hand-made ninja patch for network distribution.

Makefile generator feature was in tracker, I remember 🙂 So, ninja generator doesn’t differs match.

Jake Petroules Jake Petroules says:

We have some benchmarks which compare the speed of qbs and ninja using the Qt Creator project as a test case. For a zero build (no changes to the project), CMake+Ninja took 0.24s compared to qbs taking 0.531s (a difference which is still less than the user-perceivable threshold of 400ms). Conversely, for an incremental build where a couple of source files were touched, CMake/Ninja took 7.576s whereas qbs took only 2.008s. Remember too that Qt Creator is a non-trivial, real world project of respectable size. We’re not doing benchmarks with Hello World.

So as you can see, Ninja may be faster under certain conditions, and qbs may be faster under certain (most?) conditions as well, while still producing correct results. In any case, the gain with qbs tends to be larger than most alternatives, and *if* there is a loss with qbs, it tends to be fairly small. There are all sorts of optimizations we can do as a result of qbs’ design as well. Fast, correct: choose two.

Of course, these are preliminary benchmarks and we will release more details in the coming months when the initial port of Qt to qbs is announced. I think in the face of what qbs can do already, there’s very little value in a Ninja generator compared to how we could otherwise spend our time implementing new functionality. It will also have its inherent limitations compared to using the “native” qbs backend, like all generators.

However, from your experience helping to create the initial MSVC generator, we certainly would not be opposed to the contribution of a Ninja generator. 🙂

Lilian says:

I am not sure that it is an apples to apples comparison.
For example, CMake + Ninja even track system headers for changes(ex: updating a package) and makes sure that a correct rebuild is made if something changed.
Does Qbs offer that level of consistency?

My issue with Qbs vs CMake is that there is an entire community with even package managers in CMake(ex: hunter, or Microsoft’s vcpkg), modules for sanitizers, coverage, everything you want… It is a powerful, reliable, pretty fast, cross-platform, scriptable system that already has great support for Qt…
Also, there is great IDE support for CMake(almost every IDE there supports CMake)…

It seems that the community doesn’t have a say on this, so I decided yesterday to not express my “irritation” on this(I still try to keep my cool)…

Btw, Gradle like Gradle – why would somebody choose this over Google’s Bazel or Facebook’s Buck for C/C++ development(except for the Java dependency)?

Jake Petroules Jake Petroules says:

Qbs of course tracks changes to system headers. Actually, one of the major selling points is the increased correctness/consistency of incremental builds compared to other solutions. Since 1.8 you can use the cpp. treatSystemHeadersAsDependencies property (per-product, even!) to control whether Qbs tracks changes to system headers, to allow you to fine tune Qbs to your own preference on the spectrum of performance versus correctness.

Again, the CMake “ecosystem” argument is a valid one, but every solution that ended up being a popular one had to start out somewhere. We believe that eventually Qbs’ ecosystem will be on par with CMake’s due to the superior capabilities and productivity enhacements it affords to developers, which will result in an influx of users to help us build out that ecosystem.

One of the main design goals of Qbs was to enable better and easier IDE integration than is possible with existing build systems, by the way. Integrating CMake into IDEs is a nightmare – just ask Tobias Hunger (Qt Creator) or Stephen Kelly (KDevelop).

Lilian says:

When you said that it already tracks system headers, you sold me a bit on it.

The last time I used `qbs`(played around with qbs 1.1, 1.2 and 1.4 when these were released), I found a few issues that made me decide against it(I ported a project at work from qmake and was trying to see if I should convince my colleagues to switch to it):
– The biggest issue back then(and still seems to be somewhat an issue now) was the lacking documentation.
A lot of things were guess work. A lot of components without code examples and good explanation of what the components are doing in the background.
You can find qmake and especially CMake documentation for almost anything you want(In the case of CMake – for everything you want).

– All the profile setup was very complicated and the documentation was not helpful.
Coming from “mkdir build && cd build; qmake -r ../qt-creator; make”, it seemed overly complicated.
Compiler not detected, Qt not detected, nope you can’t go out of source, etc…
I was already hearing colleagues complaining about the toolchain setup complexity.
We also do cross-compilation and it looks like this: “source /some/env.sh(this one changes daily); qmake [path]; make” – done, no fiddling.
Also, I could not do just “qbs” or “qbs build”, it was very confusing.
Might be that it was a paradigm shift(like coming from C++ to Rust and getting annoyed that the compiler doesn’t allow you to do memory management mistakes), but I don’t think this is it.

Jake Petroules Jake Petroules says:

You’re right that there are some areas in the documentation that we could improve, and this is something we are actively working on. I think the qbs documentation is already quite good compared to qmake, for example – the lack of documentation there has been one of the most widely given criticisms of that tool over the years, and we don’t want to repeat the same mistake again.

I’m guessing the reason you feel qmake documentation was more available was due to finding more examples online, open source projects, etc., due to its longer history. In any case it would be great to know which parts of the qbs documentation you felt lacking, so that we can improve it. You can open a bug report on the qbs project at bugreports.qt.io for this and any other feedback you may have.

> “All the profile setup was very complicated and the documentation was not helpful. Coming from “mkdir build && cd build; qmake -r ../qt-creator; make”, it seemed overly complicated.”

I’m glad you mentioned that, as I agree that this was an unnecessary barrier to entry for new users. This is why we made profiles optional in 1.8 (see “Qbs can now be run without a profile […]” above).

Lilian says:

Part 2(some kind of limitation in the comments section).
– I tried to see if QtCreator builds faster with qbs(because of the speed claims in the blog posts) and it was the same as qmake + Make(actually, make was a little bit faster but the difference was too small).
This made me think that the claims were false(reading this blog-post, I understand that incremental compilations are faster).

– I looked back then at the project activity and the development was slow. Also, it was in “Qt Labs” which didn’t give much confidence either.

These are all the points why I decided that our team should not use Qbs.

Btw, all the newer/fast build systems have good support for Rust: Bazel, Buck, Meson… – there are other but these are pretty popular.
This is also not helpful.

Jake Petroules Jake Petroules says:

I think there have been some positive changes in the development pace since that time.

Rust support is something we could think about adding to qbs (QBS-1134), but it is not a priority. Our aim is to support a variety of languages and toolchains in order to grow the ecosystem beyond the singular use case of C++ and Qt.

jona yang says:

“This moves us closer to functional Android support, although there are still many tasks left to do, including support for Clang/LLVM from the Android NDK.” Then, will Qt 5.x still supporting llvm based android ndk in qmake instead of waiting young qbs devel in Qt 6.x to be mature build scheme?

Jake Petroules Jake Petroules says:

There is actually not very much left to sort out in qbs itself in order to support Clang/LLVM; someone just needs to take the time to implement and test it.

For Qt, the reason we’ve not yet switched to Clang/LLVM for builds is because of a toolchain issue that causes a significant increase in the resulting binary size. You can track the status of that here: https://github.com/android-ndk/ndk/issues/133 I can’t say exactly when we’ll switch to Clang as the default; I’d recommend getting in touch with some of the developers with more experience with the Android port, such as Eskil Abrahamsen Blomfeldt and BogDan Vatra.

That said, I think it’s quite likely you’ll be able to create Clang/LLVM builds of Qt using qbs before Qt 6 rolls around, but of course I can’t give you an absolute promise at this time.

Jean-Michaël Celerier says:

If anyone’s interested, I have a bug open with a patch to add a mkspec for android with clang / libc++ : https://bugreports.qt.io/browse/QTBUG-60455

I use it in production without problems.

jona yang says:

I’m still couldn’t imagine how internal qbs works. But, I wish I wouldn’t mess tricky linker flag build rule as cmake generate did before automatically with many other build generator. To me using json config is human readable. But it’s hard to type for lazy people which often need fast working out of box . You still need to type space tab and so on. Introducing new keywords like os.walk in Python with filtering options might help a bit.

Tobias Hunger Tobias Hunger says:

@Jake: Since you pointed to me about CMake IDE integration: CMake is pretty decent in that area nowadays.

It took me a couple of weeks to get there, but the CMake community was very welcoming. Everything I needed for Qt Creator is available upstream for a couple of CMake releases already and other IDEs have expressed interest to use the same approach, so I hope to see other parties contribute and improve the capabilities of CMake in this area further.

Qt Creators CMake support is actually rather good by now.

Philip S says:

@Jake: I’m sorry to see so many qbs critics. I drank the QBS cool-aid several years ago and haven’t looked back. I was previously using cmake, qmake, makefiles, and shell scripts. All of those build systems components made me cringe whenever I need to do something custom (such as building fortran code or protobuf) or when the automatic build system failed from an software upgrade. It was just a painful mess. The readability and customization of QBS make it a far superior tool. I love the declarative nature of QBS; it’s the perfect fit for the build system problem.

I’m very glad to hear that QBS will be used with Qt 6! It gives me hope that the project won’t be abandoned for some reason. I also like that you changed product.moduleProperty(). I never thought it was very intuitive.

Keep up the good work!!!

Lilian says:

For some reason I can’t post why I initially decided not to use Qbs…

Rune Karlsen says:

@Jake I work with security, build and release engineering and I was wondering about the modules repository functionality you are mentioning. Will it be in the line of intrusive commercial metrics like npmjs, bintray/jfrog/jcenter and Android/Google – or more in line with referencing remote extended git-urls with version-tag-hashes/-refs?

Recent such centralized failures like leftpad of Npm with all the legal implications of changing author rights or Jfrog breaking builds worldwide should be a warning to anyone not using local server caching of dependencies. Also for the sake of proper security-scanning of publicly available modules and resources, consider something that can be customized properly.

In my view it will take some effort for open source communities to embrace yet-another-repo-protocol, while commercial suppliers like Jfrog and Sonatype would be quick to offer something for a hefty price tag. E.g Jfrog hiked prices for Artifactory more than 50% around 18 months ago.

I would say that a build-system source around containers and Qbs seems very interesting, as could well be easily cross-platform, scalable etc. Also for embedded build targets since toolchains are seldom run on the actual embedded platform. Even enabling Docker-based modules for a build pipeline would be very nice for testing – both embedded, mobile and desktop.

The sub-dependency version de-duplication and locking of Yarn is also a very nice feature to consider which simplifies builds, but the main concern would be how repositories would be handled and what kind of repository-protocols are used. Keeping a central CVE-style advisory repository as a service with the actual module referencing kept open as in Git-urls seems a better and more welcome service alternative than the intrusive centralized metrics-based repositories. Please consider not encumbering build processes, but rather aiding them, when choosing your approach to such a module-based service.

Jake Petroules Jake Petroules says:

We have no concrete plans yet for exactly how qbs’ networked dependency fetching mechanism would be designed, but as it is an Open Source project, your feedback would be quite welcome and I invite you to begin a discussion on the mailing list or on our JIRA project (both of which are linked in the blog post).

I agree that security is an important concern here, and of course different users will have different requirements in the balance between security and convenience. One way to solve the sorts of problems you’re describing is to always locally cache the content of such online repositories. For example, in Xcode projects with CocoaPods you can choose to always commit the Pods directory, in Node projects you can choose to always commit the node_modules directory, and so on, so that you have the opportunity to review which changes are going into your project and what legal and technical implications that may have. There is also the advantage that your build cannot be influenced outside your own direct control, and dependencies cannot disappear.

Of course, for online repositories which provide binary versions of those dependencies (like CocoaPods), this can be a less desirable solution as it bloats the size of your own repository. I think as we consider the design of a networked extension to the qbs dependency system, the ability to fetch pre-built binary dependencies versus source-only dependencies is an important design aspect, as is the opportunity to cache remote dependencies within local infrastructure (such as mirroring third party source code repositories within your project’s own infrastructure).

Rune Karlsen says:

Git-committing node_modules/ or other such caches like .gradle/ is not very good, but Docker-committing/-building them or having them be a simple container-layer binary diff is definitely much more useful. That way dependencies and variations on build-dependency caches can be managed in a flexible and useful manner, while enjoying de-duplication through e.g a Docker registry and even e.g a Btrfs filesystem for build servers/hosts.

I think that offering a central Git and even Git LFS repository from Qt would be very nice, while still adhering to an open ecosystem and allowing use of Github, Gitlabs, Bitbucket, other web-based repos etc.

If you guys kept were open to such an embracing strategy, you could still offer (varying commercial or open) CVE-like advisory on commits, dependency-references etc. This way you could “easily” offer both source-complete, mixed-source-binary and binary-only dependencies for Qt and perhaps start a proper Qt Marketplace. 😉

HGH says:

I was considering if qbs could be a good build system for cross-platform game development – that means Visual Studio + Sony PS4 + XBox One + UWP + Android etc. but adding all that functionality might be way too much for a small team. What do you think?

Jake Petroules Jake Petroules says:

I think Qbs can be an excellent tool for cross platform game development. The platforms you mentioned are certainly not out of scope for us; we already have support for Visual Studio and Android, with UWP on the way.

The console platforms like Xbox One and PS4 may be more challenging given their closed nature, meaning it is difficult to obtain the SDKs, and there may be additional legal challenges involved with distribution depending on the nature and level of support. However, I imagine the Xbox One SDK is based on Visual Studio tooling, and PS4 is based on Clang and FreeBSD, which we already support, so the technical barriers may be relatively low. This is something I’ll have to investigate at some point.

HGH says:

All current console SDKs integrate into Visual Studio. I have no access to Nintendo Switch so I don’t know about it for sure but I guess its SDK will too.

The biggest problem I see is that the console vendors might not allow to publish the code publicly.

Zakhar says:

I’m happy to see the QNX support out of the box. It took a lot of time to make it work on my own(and it still did not work properly). I’m still wondering, why is there no support to run an executable on the QNX device by ctrl+R(like with qmake)? Qt creator finishes on the deploy step and asks to choose a custom executable.

Jake Petroules Jake Petroules says:

Sorry to hear the QNX support is not working for you (it was tested primarily on Unix platforms). Thank you for your bug reports, and we’ll look into getting these issues fixed as soon as possible, hopefully for a 1.8.1 release.

There is no support to run an executable on a device because we haven’t yet integrated Qt Creator’s remote target run support with the Qbs build tool plugin. This is something the Qt Creator team will implement in the future.

Danny says:

I’ve been using QBS in my own projects and I like it for the most part but I do have some issues with it:

1) It’s locked into the Qt ecosystem.

Unlike premake (http://premake.github.io/) or CMake, it cannot generate make files or project files for other IDEs which makes it a really hard sell in an established team environment.

I also sometimes get strange internal warnings and errors that are difficult to diagnose.

I really like that premake is a simple self contained binary that uses a declerative syntax. QBS requires Qt to be installed which is a massive dependency.

2) It’s C++ centric.

The project I’m working on is C/Objective-C. I’ve been able to make it work with the cpp module but the nomenclature is C++ specific and unintuitive. I still have to create a ‘cpp’ project.

3) The documentation is bad.

I know this has been mentioned already but the documentation is inadequate.

4) No way to run bash/command shell commands.

In the real world, build systems need to be able to run platform native scripts. I couldn’t see anyway to make this work with QBS. I don’t mean cross platform abstractions or JS, I mean actual native shell commands.

Christian Kandeler Christian Kandeler says:

1) There is a generator for Visual Studio, and one for XCode will follow. I don’t see why you would want to create Makefiles.
Regarding the “strange internal warnings”, that’s hard to comment on without examples. Bug reports welcome.
2) The cpp module handles the entire “C family”. As far as I know, all languages in there have the same level of support. Can you explain in what way it was harder to “make it work” for Objective-C compared to C++?
3) Feel free to open a bug report for cases where you find the documentation is letting you down.
4) I don’t understand what that means. What is so special about running scripts and why do you think you cannot do it?

Jake Petroules Jake Petroules says:

1) Qbs is NOT locked into the Qt ecosystem, and in fact this is one of the primary design goals. We want to build a Qbs ecosystem.

You CAN generate project files for other IDEs. Currently we support Visual Studio, and Xcode support is under development. You can find some preliminary documentation here: https://doc-snapshots.qt.io/qbs/generators.html

“I really like that premake is a simple self contained binary that uses a declerative syntax. Qbs requires Qt to be installed which is a massive dependency.”… it’s possible that will go away eventually. We are looking into porting Qbs to use standard C++ without any Qt dependency in the longer term.

2) It’s not C++ centric. Again, this is one of the design goals: the primitives provided by the Qbs build engine can be used to build any type of project and any language. We additionally support C#, Java, and TypeScript, and have many more non-C++ modules which build other things like archive files (zip, tar.gz, etc.), installers like WiX and NSIS, Apple asset catalogs and storyboards, and so on. Read the full list at: http://doc.qt.io/qbs/list-of-modules.html

C, C++, Objective-C and Objective-C++ support are all provided by a single “cpp” module, because the implementation details of these languages are 99% the same. I’m not sure why this is a problem for your project… if you could provide more specific details then we may be able to fix any issues that may be present. That said, we may end up dividing the cpp module into multiple modules in the future for semantic correctness.

3) We are very much aware of the documentation issue and in fact just discussed in our last meeting how to make significant improvements in this area.

4) This is exactly what the Command class, which you create in the prepare script of a Rule, is for (see http://doc.qt.io/qbs/commands.html for documentation). You can also read the Rule documentation (http://doc.qt.io/qbs/rule-item.html) for how this would get used.

I’m not sure what you mean by “actual native shell commands”. There should be no reason why the cross platform Command abstraction is insufficient for your needs because it handles proper argument quoting for you automatically, and provides better abstractions for external process execution than you get with pure shell scripts anyways.

If you truly need a shell command for some reason, you can always construct a Command like:
new Command(["sh", "-c", "foo bar baz"])
or:
new Command("cmd.exe", ["/c", "my command string \"with arguments\" here"])

and the given string will be passed verbatim to the command interpreter / shell.

Can you provide more information about exactly which issues you’ve run into when trying to run shell commands in Qbs?

Danny says:

Thank you for your reply. If anything this further illustrates the poor documentation and examples.

Jake Petroules Jake Petroules says:

Perhaps you could create some JIRA tickets indicating your specific pain points so that we can improve the documentation and examples for the benefit of you and other users going forward.

Commenting closed.

Get started today with Qt Download now