Qbs has reached a state where it's conveniently possible to build projects of the complexity of Qt Creator. Therefore it deserves a version number that reflects its usefulness to the public. To encourage you to use it for your own projects, we hereby present to you qbs 1.0.0.
Why should I use it?
- Qbs takes care of your build environment. Build your project for different platforms in the same shell.
- Build multiple configurations of your project in parallel.
- Fast incremental builds. A speed comparision is here.
- QMLish language. Write your complicated tasks in JavaScript instead of some obscure language (I'm looking at you, qmake).
- Qbs is supported in Qt Creator 2.8.
- Qbs is not tied to the Qt version. That means switching the Qt version doesn't automatically switch your build tool version.
Where can I get it?
Qt Creator 2.8 will come with qbs integrated.
Instruction how to build qbs from source can be found in the wiki: http://qt-project.org/wiki/qbs
Please report any bugs you may find at https://bugreports.qt-project.org/browse/QBS
Please ask your questions on our mailing list at http://lists.qt-project.org/mailman/listinfo/qbs
Can it build Qt?
This is a question that arises very often. Though it would be possible to replace the current qmake-based build system of Qt with qbs, we still would need a configure script and our infamous syncqt. I don't see much gained from that. We're aiming somewhat higher and want to replace configure and syncqt as well. That's where qbs still lacks features. Also, bootstrapping qbs is not possible yet.
Commenting for this post has ended.
Great news ! I was waiting QBS for such a looooong time !
I love the idea of a QML project file langage for my QML based apps !
Congratulations, great job!
But what about documentation? It seems doc misses a lot of things. Last time i tried abs, i didn't understood what should i use to deploy mac os applications (i.e. do the job currently done by macdeployqt tool, or at least run that tool from qbs)
+1 for the documentation. I know they are still working on making Qbs strong enough but without a bit of good docs it is difficult for people to try for those who already new something try something new.
Even then congratulations.
There's a documentation snapshot available here: http://doc-snapshot.qt-proj...
A very early adopter even wrote a little qmake-to-qbs quick ref: http://qt-project.org/wiki/...
Why QML? The "complicated tasks" that you need an embedded imperative language for are almost invariably shell commands, so why not a language more suited to the shell? Like the bourne shell or a subset of bourne shell?
QBS aims to use a declarative language, where some bits will fall back to an imperative one. For that, you need a language that already exists, and that is easily embeddable. Given that in Qt there is already a declarative language which can be extended in an imperative one, is a no-brainer, IMHO. :-)
Could qbs generate Visual Studio or Eclipse project files?
P.S: The QtCreator is a great tool, but I'm most familiar with Eclipse/CDT. For example the handling of the debugger seems much more comfortable to me in Eclipse than in the Creator.
QBS is meant to directly execute the build commands, i.e. compiler, linker, or custom step, not to create intermediate representations that are then used to buid. Going down that route would spoil most of the performance advantage it has.
For the perceived debugging comfort I would appreciate to have feature requests on bugreports.qt-project.org.
Is there a support in Qt Creator 2.8 Beta? How can I enable/use it?
Enable the "Qbs Project Manager" via Help->Plugins and restart Creator. When building from source, call "git submodule init" and "git submodule update" before running qmake; otherwise, the plugin won't be built.
I was wondering if there any wizzards but you have answered that below. Thank you!
This looks very promising. Just a few comments/questions:
(1) The build progress bar for a QBS-based project in Qt Creator 2.8 beta doesn't seem to update very often (never seems to reach 100% either). Is this something that will be fixed for Qt Creator 2.8 final?
(2) Will Qt Creator 2.8 come with a wizard for a QBS-based project? That would be helpful to encourage adoption.
(3) Will there be any documentation on how to port an existing qmake-based project to QBS?
(1) There are known problems with the progress bar, but it should always reach 100%. If you can reproduce the problem, please file a bug report at bugreports.qt-project.org, attaching a project that exhibits the behavior. It would also be helpful to know whether qbs on the command has the same problem (option "--show-progress", currently Unix-only).
(2) Not in 2.8, but certainly eventually. We do not have a concrete plan yet, because other issues are more pressing.
(3) I agree that we absolutely need this. Not just for qmake, but also for other build systems such as cmake or just plain Makefiles. Feel free to add a task at the bug tracker to keep us on our toes about this. In the meantime, comparing the Qt Creator pro/pri files to the qbs ones will certainly help anyone trying to port their project.
Found answer to question (3): http://qt-project.org/wiki/...
One other question I have is how future-proof is QBS? Is this what Qt-based projects will standardize on now? I ask because we are working on a new Qt-based project that has only recently started development and want to make sure that if we were to switch to QBS that the Qt community is heading in this direction away from qmake.
Well, they have a roadmap on the qbs page for at least a year upto version 1.4.
To answer this, one would need to be able to look into the future, which we, awesome as we may be, cannot do yet. All we can say is that we are confident that qbs is a better solution for non-trivial projects than qmake and other two-stage build systems. Whether or not it will see adoption by the community on a large scale is a complex question depending on many factors, not all of which we can influence.
Good questions are asked, i just wanna know where can we expect the answers?
That's mean it time to leave qmake?
Hello, I have a naive question.
Right now (qmake) I have a problem with my build setup where the header dependency is not aways detected correctly. I have to manually alter some .cpp file, that use the header I have changed, to force it rebuild.
My question is will Qbs will solve this problem for me?
Thank You
Yes, qbs has direct knowledge of dependencies and their status and therefore knows when rebuilding is necessary. Though this kind of thing should normally also work with qmake, unless the project structure changes in some significant way.
Try adding depend_includepath to CONFIG in qmake...
I really don't understand why it is not the default
It is in Qt 5.
Hello,
Why do you reinventing the wheel, by writing a new build system and not using cmake?
What QBS has to offer that cmake doesn't and even if there is something missing from
cmake why is it better to write something new instead of adding the missing features to cmake?
Have you spent some time reading the past blog posts on the issue with the corresponding links? CMake is mature and good, but is very difficult if not impossible to integrate with tooling at the level that is expected to be done by the Qt Creator guys. Also, with CMake one has to learn a new, ugly language. Qbs is declarative, and you fall back to a well known imperative one that is already working in/with/for Qt.
Also, Qbs doesn't generate intermediate files. It runs everything, which is potentially easier to debug. There is no way to contribute the Qbs features to CMake without rewriting it from scratch.
I really don't understand this "why do you reinventing the wheel?" comments in general. If nobody ever try something new instead of an old used one, how can we progress?
And actually CMake is really ugly and barely working, it's just 10 layers of hackish, workaround mass. I will be happy to drop it without looking back if qbs or anything else is mature enough to cover all my use cases...
Absolutely agree with tr3w here.
I partly agree with tr3w here.
Cmake is too warty to be used. It is a good product, but imho they did not start with a clean enough slate.
Even if there are other declarative build systems being developed, since none are a clear winner I don't even mind Digia reinventing things with qbs. (Though Tup is looks pretty darn good)
My concern is that making qbs usable for non-Qt users is not a stated priority. If it does not get a wider audience, we'll still be stuck maintaining a non-trivial "just for Qt" build system.
Plus, I really don't buy the whole "Qt has oh-so-special complex needs" argument.
There are plenty of other large code bases in the wild could could gain from a modern declarative build system, if only Digia will take the time ensure more general needs are factored in. (Keeping Qt dependencies to a minimum, etc.)
I agree that making QBS as Qt-independent as possible should be a design goal. The fact that QBS is not tied to a Qt version seems like a step in the right direction. From the QBS project files I have looked at so far, none seem to require any Qt-specific stuff. Is there anything else major in QBS that is tied to Qt? Anything keeping QBS from being easily used as a standalone build system for non-Qt apps?
I think it needs to work really well with Java so that Qt on Android is easy to build, and so I don't have to use Ant or Maven anymore.
@David, @fonzi337: No need for concern - making qbs usable for non-Qt users is already possible and perfectly feasible. I don't know whether this has been explicitly stated, but the design of QBS itself, and the fact that it will (soon) have standalone binary distributions available for download, all clearly point towards this. We have plenty of test cases that don't utilize any Qt code, and Qt specific code is mainly isolated in its own set of modules.
So, I think QBS has great potential to be wide-reaching even into projects that don't use Qt.
@Lunarcloud: QBS is designed to be language independent (though we can only currently build C-family code right now). There are open issues regarding implementation of Java and C# support; see https://bugreports.qt-proje... and https://bugreports.qt-proje....
Why another building system? What about the Gradle for example? Or another already existing (mature enough) one?
Very perspective thing. Than realesed QtCreator 2.8.0 we try to convert our C++/boost non Qt project to this thing. Becouse its fresh, have good syntax and not a "spike" like cmake for make. I think this project get more faster iterations in developing than ide realeased.
Can QBS use FSCTLENUMUSN_DATA for fast file enumerate on NTFS http://bakins-bits.com/word... ?
Qbs enumerates files only when expanding wildcards.
I doubt that using FSCTLENUMUSN_DATA would improve the overall performance much but feel free to experiment.
What I do not get from this post is the interface compatibility promises which would probably be a very important information to know for many of us.
Nice work, but I am an old-fashioned cmake hacker ;-), and will probably stick to it. Declarative language is probably not the only way. Regardless, I say nice work, because it is nice to have a choice for the syntax. Sugar is different for different people.
The promise is that the frontend interface is considered to be stable and gets only additions and if we have to do change parts in an incompatible way we'll provide fallbacks. If that's not possible, the language version must be incremented.
As QML is a big part of QT's future, does qbs aspire to simplify how qtcreator finds QML plugins, backed by C++?
What's the problem with Qt Creator finding QML plugins?
I like it. I didn't think I would, but I actually like it!
Does it support Qt4? Or can it build only Qt5 projects? (I'm referring to ease of use, of course. An answer that goes like "yes, if you do it all manually" means "no.")
Qt4 projects are supported. No special manual handling needed.