Sometimes, development efforts align such that new use cases can be enabled with modest extra effort. The QtBase dev branch (which will become Qt 5.12) now has experimental Vulkan support, courtesy of MoltenVK and prior work in Qt. Let's take a look at what has happened.
Backstory
Last year, Laszlo wrote about Vulkan support in Qt on Windows, Linux, and Android. This work included adding QSurface::VulkanSurface and also adding cross-platform classes such as QVulkanInstance and QVulkanWindow
Then, a couple of months ago, the MoltenVK Vulkan to Metal translation library was open sourced. One of the issues raised in the bug reporter was how to make this work with Qt; this requires configuring the NSView used by QWindow to be layer-backed by a CAMetalLayer.
And, as it happens we were already looking at making use of Metal in Qt, starting with adding support for CAMetalLayer as a backing layer. We’re also looking at different ways to integrate application Metal code with Qt, but that’s a topic for another blogpost.
// Snippet from Qt internal layer management code
@implementation QT_MANGLE_NAMESPACE(QNSView) (DrawingAPI)
- (NSViewLayerContentsRedrawPolicy)layerContentsRedrawPolicy
{
// We need to set this this excplicitly since the super implementation
// returns LayerContentsRedrawNever for custom layers like CAMetalLayer.
return NSViewLayerContentsRedrawDuringViewResize;
}
- (void)updateMetalLayerDrawableSize:(CAMetalLayer *)layer
{
CGSize drawableSize = layer.bounds.size;
drawableSize.width *= layer.contentsScale;
drawableSize.height *= layer.contentsScale;
layer.drawableSize = drawableSize;
}
- (void)layoutSublayersOfLayer:(CALayer *)layer
{
if ([layer isKindOfClass:CAMetalLayer.class])
[self updateMetalLayerDrawableSize:static_cast(layer)];
}
- (void)viewDidChangeBackingProperties
{
CALayer *layer = self.layer;
if (!layer)
return;
layer.contentsScale = self.window.backingScaleFactor;
// Metal layers must be manually updated on e.g. screen change
if ([layer isKindOfClass:CAMetalLayer.class]) {
[self updateMetalLayerDrawableSize:static_cast(layer)];
[self setNeedsDisplay:YES];
}
}
@end
With all this in place the missing parts was then the platform plugin glue code which adds support for QSurface::VulkanSurface (on macOS) and also implements a QPlatformVulkanInstance subclass that abstracts over platform-specific Vulkan tasks such as creating a Vulkan surface for a native surface.
How do I use it?
The minimal way
Call setSurfaceType(QSurface::VulkanSurface) in the constructor of your QWindow subclass. You can now access the NSView with QWindow::winId(), and pass that on to MoltenVK. The NSView is configured in such a way that MoltenVK can render to it. See also MotelVK issue #78 for more info. Note that I have not actually tried this myself :)
This does not require enabling Vulkan support when building Qt, which again means that the Qt binary package can be used (from 5.12 onwards).
The using the Qt API way
This makes using QVulkanWindow and friends possible, at the cost of having to build Qt from source.
Configure and build Qt with Vulkan support by adding the MoltenVK includes (build MoltenVK according to instructions first):
./confgure -I /path/to/MoltenVK/Package/Release/MoltenVK/include
You should now see "Vulkan: yes" on the configure report; if so the QVulkan* classes are available.
Then, tell Qt the location of libMoltenVK.dylib before starting apps or examples:
export QT_VULKAN_LIB=
/path/to/MoltenVK/Package/Release/MoltenVK/macOS/libMoltenVK
This re-uses the existing Qt code which loads and resolves the Vulcan library at run-time. On macOS we might want to link against MoltenVK.framework instead, but we'll leave that as a future improvement for now.
Finally
I'd like to round off by repeating the "experimental" warning. In particular we don't have enough insight into the inner workings of MoltenVK to know if there are potential points of incompatibility. Please report any findings below or in a QTBUG.
Why not CMake, Meson, or automake? There are so many build systems out there already.
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://www.qt.io/blog/2017/..., to avoid repeating the same answers again and again.
When does the development of QBS started?
Development of Qbs began around 2011-2012.
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.
But people actually use Meson.
So the people who use Qbs don't exist because you say so. Right...
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).
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!
> 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/r... at more than 1/3rd of developer marketshare.
Likewise for MS : https://blogs.msdn.microsof...
" 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.
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, ...
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.
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.
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.
Is it possible to create Android and iOS applications ?
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).
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!
This is in progress for all Qt examples. Unfortunately I can't give you any date by when we might be finished.
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)
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?
Thank you for your support!
We actually already do support building Windows installers - there are dedicated modules for:
Qt Installer Framework support will come in a future release and is being tracked here: https://bugreports.qt.io/br...
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?
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.
> 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.
https://cmake.org/cmake/hel...
if this is "long and complex" we seriously have other problems:
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.
> 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/hel... 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.
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.
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.
As mentioned in the post, precompiled headers are now activated by default. Just add the file tag "cpppchsrc" 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.
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.
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.
Chris
[1] https://www.mail-archive.co...
Last commit to meta-qt3 was on 2016-08-29, a year ago!
> 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.
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.
We've discussed this recently and plan to look into it at some point. The issue is being tracked in JIRA as QBS-1188.
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.
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.
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.
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?
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?
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/br... for details and a workaround.
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) "$QBSEXE" build -d "$BUILDDIR" -f "$PROJECTPATH" -p "$BUILDPRODUCT" --jobs 4 profile:"$QTPROFILENAME" qbs.architecture:x8664 release
2) "$QTBINPATH/macdeployqt" "$BUILDDIR/release/install-root/$BUILD_PRODUCT.app" -dmg -qmldir="$SCRIPT_PATH/app/qml"
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.
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.
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.
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.
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?
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.
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?