Tuukka Turunen

Deprecation of Qbs

Published Monday October 29th, 2018
200 Comments on Deprecation of Qbs
Posted in Build system, Dev Loop

The Qt Company has been supporting three different build systems for Qt programs. For Qt users, qmake is currently the most widely used build system. CMake is a clear second and growing in popularity. The third place is Qbs, with significantly smaller adoption. When asked about their preferences, most of our customers said they plan to use either CMake or qmake in the future.

We have decided to deprecate Qbs and redirect our resources to increase support for CMake. Qbs will remain supported until the end of 2019 with the last planned release in April 2019, together with Qt Creator 4.9. Qbs is available under both commercial and open-source licenses, and we are happy to continue providing the infrastructure for further development by the Qt Project community.

To summarize the key points:

  • Qbs will continue to be supported until end of 2019
  • Last Qbs release will come out in April 2019
  • Qbs continues to work with upcoming Qt Creator 4.8 and Qt Creator 4.9
  • Qbs library and tools will be available under Qt Project for possible further development by the community
  • Support for qmake will continue unaffected
  • Support for CMake will improve
  • Longer term, we plan to switch to CMake for building Qt itself
  • CMake support in Qt Creator will be further improved

Deprecating Qbs allows us to significantly improve CMake support. We believe this change will help the growing number of our customers who prefer to use the CMake build system. Beneficial is also CMake’s wide adoption outside Qt and its active development ecosystem.

Do you like this? Share it
Share on LinkedInGoogle+Share on FacebookTweet about this on Twitter

Posted in Build system, Dev Loop


Sune says:

This is a very good decision I think. While CMake is often less than beautiful, it is still the least-bad build system I have tried. And it have a very large user base. Focusing the efforts there definitely makes sense.

Thank you.

HGH says:

May Microsoft buy Qt!

Or even worse:

May Apple by Qt!

Gigi says:

Please better support ‘install’ for Qt modules in CMake ❤
It’s always a pain to do it correctly

Andreas says:

As a user of cmake and Qt, I think this is great news, as it may lead to an even better cmake+Qt experience in the future assuming more resources will now be designated to cmake-support.

I sympathize with everyone that have invested in QBS though, and I hope that they will bring with them some of the improvements qbs has over cmake into cmake over time.

Samuel Sarette says:

I hope CMake grows the ability to create installers / packages / app bundles. That was one of my favorite parts of Qbs (and the simple syntax).

Adriaan de Groot says:

Does CPack (https://cmake.org/cmake/help/v3.12/manual/cpack.1.html) not do what you want? If the CMakeLists.txt is set up correctly, then you *should* be able to do “cpack -G ” and get a suitable artifact. It (CPack) can create .deb and .rpm and .pkg , and NSIS installers, and my copy even claims to create “Qt Installer Framework” packages, whatever those are. So you may already have what you want (and if not, that’s something to keep working on — the CPack generators are not all that complicated, I wrote the .pkg one in a couple of hobby-days).

Ugly syntax .. well, let’s not argue about that (maybe we can agree on “it’s gotten better since CMake 2.0”).

Steve says:

I was recently wondering what the status of qbs was as it has been receiving updates but not being pushed, so it is useful to have a clear statement of intent (although typically I had just starting experimenting with qbs).

IIRC, qbs was intended as a replacement for qmake. Does CMake now fulfill that role: i.e. is the intention to retire qmake at some point (once all features are supported in CMake)?

What is the current build system that is recommended for Qt + Android? Is CMake ready for this yet?

@Steve: Yes, longer term we want to phase out qmake for building Qt itself and use CMake instead. Even after that qmake can be used for building applications. We of course continue to offer pre-built binaries, which most of the Qt users prefer.

Marius says:

To answer your last question about CMake being ready for Android: I wouldn’t consider it ready. Especially when it comes to integration with Qt Creator. I also had to create my own CMake module to invoke androiddeployqt. (There would have been an ECM module but it had too many bugs to be worked around in my case.)

Samuel Sarette says:

I hope CMake grows or has the ability to create installers / packages / app bundles. That was one of my favorite parts of Qbs (and the simple syntax).

Eli says:

Noooooo 🙁 cmake is so ugly and qbs had so much more potential…

Mousavi says:

Agree +1

d3fault says:

Agree +2

I’ve been eyeballing Qbs and planning on switching to it for a while (sure glad I never didn’t now, like some other unlucky commenters)… Qbs is cleaner and simpler than Qmake, but I also understand the argument of wanting to focus less on reinventing the wheel (free up resources to work on Qt itself).

Here’s the thing, I don’t understand the appeal of CMake. I’ve used it to build other people’s software and it functions just fine and dandy, but as for using CMake with my own software I’ve dabbled here and there, read a few tutorials… and the system is just so bloated (overly verbose) and tedious and time consuming to setup… that I honestly prefer Qmake over it… even for non-Qt projects (QT -= core). Whenever I open up a CMakeList.txt file I feel like I’m basically looking at a Makefile in terms of readability. Am I missing something? CMake being “powerful” is a bad argument: so is x86 assembly, and yet we prefer C++ because of it’s simplicity.

What if (and I’m just vomitting up this idea) the next version of Qbs simply generated CMakeList.txt files?

d3fault says:

What’s the CMake equiv of the “qmake -project” command? Obv just listing headers/sources in CMakeLists.txt isn’t enough, the Qt libs need to be referenced as well. Maybe there could be “cmake -qtproject” to mirror “qmake -project”? For a lot of simple Qt apps missing .pro files, “qmake -project && qmake && make” just works… but at the very least “qmake -project” gives you a good starting point.

QtCreator has been adding more support for CMake over the years, so the above is probably n/a to QtCreator, but there should still be a non-tedious way to set all this up from the command line and a non-graphical text editor (maybe there already is? there certainly could be).

Alexandre says:

Agree +3

koval says:

Qbs is so much faster than cmake. I have a project where “Scanning dependencies…” step takes 5 minutes after changing 1 file. QMake and Qbs handle that instantly.
Qbs has cleaner way to represent multi-way dependencies between artifacts, requries no additional tools to perform the build (no make/ninja/jom).
I literally hate cmake. It was more fun for me to do module-like system for old (Qt4-based) Qmake than to use this I-have-no-idea-why-it-is-so-popular awful tool. Did the cmake authors ever heard of functions? Pieces of code that can return values? I think not, they only support out parameters to procedures. WTF?! Even Pl/SQL has both functions and procedures.
If Qbs is deprecated, well – I will never switch to cmake. Rather I would take the last released sources somewhere and add new features myself…

@Eli: Qbs is open-source. Has been from the beginning. Developed under the Qt Project. Everyone is able develop it further, but very few have done that except for Qt employees. As I said in the blog post, we are happy to continue providing the environment to continue developing Qbs and can help in reviews etc. So this is a good opportunity for community to pick up – as we are still working on Qbs towards the April release and supporting it throughout 2019. Qbs is found at: https://codereview.qt-project.org/#/admin/projects/qbs/qbs and information about the Qt Project and how to contribute at: https://wiki.qt.io/Qt_Contribution_Guidelines.

黄其泽 says:

CMake is more widely used by c++ projects. But is not an good enough build system yet. The DSL language of CMake is hard to learn and lack many features like package repositity support.

Do Qt company consider Meson Build? It is used by Mesa and Wayland.

Tobias Hunger Tobias Hunger says:

Meson is a great build tool. I would welcome contributions to get that fully supported in Qt Creator. There is a plugin on github, but it unfortunately is not part of the code we ship. That is one reason to not make it past the first round: We need a build tool that is supported by upstream Qt Creator.

Meson is also a bit inconvenient to use in huge projects when you end up with lots of very similar libraries/plugins/tests. So far it does not allow for custom target types. When e.g. porting all Qt Creator plugins to meson this leads to very repetitive meson build definitions. Those are tiresome to write and it is really painful whenever you have to update something that effects all plugins.

I hope meson will come up with a good solution to avoid these repetitions and will continue to keep an eye on this promising project.

Marvin Scholz says:

I’ve been working on porting VLC media player to meson, which has a lot of modules and I
ended up in a similar situation.
Luckily recent meson versions support dictionaries so I just create an array of dictionaries, one for
each module with the non-common stuff and use that in a foreach to build the modules
without having to duplicate all the common options.
Maybe that could work for your case too.

Eli says:

Why not meson?

Ray Donnelly says:

What a truly awful decision. Cmake is horrible legacy software while qbs was awesome. Enumerating the consb if Cmake would take a blog series.

I just hope never to have to build Qt6.

Maximilian Hrabowski says:

What a pity.

We just finished an evaluation whether to port our build system to cmake or qbs: Qbs won because of much clearer syntax, better extendability and much better capabilities when handling generated code and packaging. Seems we need to rethink our decision.

If you ask me you should deprecate qmake.

Somehow reminds me to what had happened to Beta vs. VHS. Or Meago.

nrw says:

Qbs is buggy for huge projects. I was happy to convert all my projects to cmake year ago.

Maximilian Hrabowski says:

Buggy in what terms? Just worked for us.

o says:

We identified some bugs that have been fixed since then (Qbs 1.12.0), got rather big projects running now with good results.

Alex says:

I get your point, but to me, qmake is the least-bad cross-platform build system with by far the simplest and clearest syntax of anything I’ve seen. Simple, effective, easily maintainable. The only complaint I have, really, is that the Visual Studio generator can’t produce filters (“folders”). So, while I get your opinion, I’m super happy qmake isn’t going away any time soon.

John says:

>but to me, qmake is the least-bad cross-platform build system with by far the simplest and clearest syntax of anything I’ve seen.

Obviosly you have not seen QBS project files.

Nikos says:

CMake is the build system almost everyone uses, but also almost everyone hates. I think it’s fair to say that most of us are looking towards Meson instead.

Vladyslav Stelmakhovskyi says:

cmake is a mess 🙁

Robert says:

I understand your reasoning, but that’s really a pity. We considered porting our large project from qmake to qbs. A prototype showed great improvement in build times.

John says:

Just ported relativly big project to QBS from hand-written makefiles and we are really happy about the result and process. We managed to fully reproduce old project structure/build process (inspired by limitations of makefiles, IDE’s from 90th ets). Documentation and project files from qbs sources were all we need. This decision is very disappointing.

As far as I can see from QBS mailing list there are just 2-3 people in the best case who works on it. How rearranging them will significantly increase support of CMake?

Tim says:

This is a huge loss for the future of Qt. CMake is an ugly, badly documented mess, while QMake is already showing its age. Qbs was a good option for the future. My opinion is well expressed on this web site: http://nooooooooooooooo.com/

At least go for something more modern that CMake please.

Robert says:

“For Qt users, qmake is currently the most widely used build system. CMake is a clear second and growing in popularity. The third place is Qbs, with significantly smaller adoption. ”

How did you measure that, and what are the growth rates?

E.T. says:

That’s a very sad decision. Once again the worse, but unfortunately more popular thing has won the game. Apparently the really good ideas don’t stand a chance in our world anymore.

Vladimir says:

“The third place is Qbs, with significantly smaller adoption.”

Because of significantly smaller functionality, documentation, examples and support overall? It had much more unrealized potential (better syntax, better support of complex projects with modules including modules, better performance)…

Thomas BOUTROUE says:


I’m happy user of Qbs since years, I find Cmake cumbersome and unproductive, while QMake is ridiculously limited.

I love the very generic architecture of Qbs, and the clear syntax (QML).

I was eagerly waiting for Qt Company to deprecated Qmake and focus fully on Qbs…

Seems that I’ll have to stay with an unmaintained Qbs, as there is NO WAY I would switch to Cmake.

The makefile-generators (like QMake and CMake) lived their long life, it’s time to let them die.

Please rethink, and btw, publish the popularity survey that made you do this pityfull decision, as far as I’m concerned I have not been asked…

@Thomas: The question I was referring to was part of a customer survey sent to all commercial license holders. But that is certainly not the only data we have been looking into. We also saw technical merit in Qbs – and that is why we were investing into it for many years. This was no easy decision to make and we did consider it from multiple angles.

Thomas BOUTROUE says:

I do have HUNDREDS of projects using Qbs, I will not migrate to CMake (I didn’t in first place, with a reason), so how will I build my apps with future versions of Qt and QtCreator ? Will Qbs still be included in QtCreator even if receiving no new feature, or will it be dismiss altogether forcing us to stay on obsolete version of the IDE ?

Ola Røer Thorsen says:

We have the commercial license, but were never asked about a preferred build system (we’re using Qbs all over).

@Ola: Build system plans was asked in conjunction of a larger customer survey a while ago.

Robert says:

I suppose you talk about the survey that was sent out in November 2017. Sad to say, I never got round to it.

John says:

And QBS got significant boost only during last two years.

Ola Røer Thorsen says:

Can’t see that we did get any survey to fill out about that!

Mad says:

Thats sad to hear, I had high hopes for qbs.

Pier Luigi Fiorini says:

I feel like qbs was never given a chance to shine.
I know that you developed it for years but only recently you made an effort with documentation and examples, but that was not enough. qbs needed to be pushed in order to increase its popularity.

boris says:

If anyone is looking for an alternative *native* build system, there is build2 (https://build2.org).

Thomas Sondergaard says:

Good decision. CMake is not perfect, but it is in widespread use and we all benefit if we avoid further fragmentation here.

Jakub Narolewski says:

Well, there goes my hopes and dreams of never touching cmake again 😛

ac says:

This is such bad news, as others have commented above qbs hasn’t really been given a chance and even as it is today is already so much better build system than cmake

Borgar says:

Really sad news!

Scylla says:

That was my hope. Love it.

Michał says:

It’s a step backwards. Qbs is better than CMake in almost every aspect, except popularity and adoption. They are not even on par, because Qbs is a complete build automation tool, while CMake is Make’s wheelchair with cybernetic arm (same as QMake or Autotools).

Ivan says:

I suppose, most commercial users used qmake not because it is better than qbs or cmake, but because it is native tool for Qt development, it is documented and works “from the box”.
If they google for a “crossplatform build system” they definitely find only CMake.
My thought is – nobody uses QBS (ok, I use for all my projects, but I don’t pay you money) because they even doesn’t know about it’s existence. “What build system we should use? – cmake, of course! – Did you try QBS – nope”. No kidding, Thiago, who wrote a post in dev mailing list about Qt6 build system requirements never even tried QBS)
QBS never had a chance to get out of a sandbox or playground project.
For me, you’d better deprecate QMake – from my point of view, 2 people working on QBS is nothing compared to new features to qmake that was added during several years. QMake is extremely slow and inefficient – qtbase/src opens for the whole minute or two on the latest Mac book pro, I can make me a tea while it is opening=)
To conclude, I personally think you made a wrong decision and you had to give QBS a chance. Using qbs as a default build system for Qt6 was that chance.

Pier Luigi Fiorini says:

I totally agree with you Ivan, and I want to add that a couple of years ago it felt that TQtC decided that Qbs was in fact going to replace qmake as the Qt 6 build system, only to deprecate it today.

In hindsight those last 2 years could have been better spent improving CMake support for Qt, even more than it was already done.
That would not have solved CMake ugliness but at least we would already have an improved IDE.

hilefoks says:

We use qmake instead of qbs or cmake because the last ones didn’t exist. Many commercial developers cannot constantly change their infrastructure (build system, version control, CI system, frameworks, …). Our Software was written with Qt2 and still uses qmake, Qt4, Subversion. Yes, that’s terribly old, but that’s how commercial software products (especially medical software) works. We just cannot fundamentally change our software every 3-5 years.

qbs was never an option, even in newer products, because it was too young. cmake is slowly becoming an option – especially because it is becoming the industry standard and because Visual Studio supports it natively.

Meson… maybe in 10 years… oh wait… it’s written in Python?

John says:

Complitly agree with Ivan. It looks like choosing Subversion over git in 2010: Subversion was the most popular, but obvisoly already outdated technology.

Everything in CMake looks so much ugly comparing to QBS.

Vikas says:

Also never saw an official QBS or even a QMake generator for QtCreator for CMake. Primary reason why we could not switch to QTCreator IDE with our existing Cmake environment and now we will retool everything to CMake again and cross our fingers on server mode. Man.

John says:

What do you mean “never saw an official QBS or even a QMake generator for QtCreator for CMake. “?

QBS is a replacement for CMake and QMake.

Arthur says:

Defaulting Qbs in Qt6 was by far the best decision, qmake is more used ONLY because it works out of the box

Paul says:

It was literally yesterday I decided that I was going to get up to speed on QBS and port all my qmake projects.
CMake is terrible.
I’ve used http://www.fastbuild.org/ on a few projects as well, and that, while a lot more complicated to get working, is pretty awesome. FastBuild also takes charge of doing all the compiling, rather than generating project files.

Andy says:

While I respect your decision – and appreciate that you are being direct about it – I think it’s unfortunate because cmake is a mess. Terrible user experience.

I have two large projects – one using qmake and one using cmake. The cmake one is horrible to develop and maintain. I was hoping to avoid cmake again for any future projects.

None of the Qt docs I’ve read mention qbs as an option, nor do any of the examples in the Qt docs use it (that I’ve seen). I thought it was still an experiment that wasn’t ready for prime time yet, so I never really looked at it. I was waiting for it to be released 🙂

Robert says:

I second that. I felt that qbs was still in an experimental stage, because it still wasn’t the default build system in Creator.

Dmitry says:

The most disgusting news of the year. We waited for the improvement of qbs system. So we are very sad and embarrassed.

Michael says:

CMake is horrible legacy system that is widely used only because there was nothing better when it was invented. Alternatives are pretty wonky being written in Python (Meson) or in Java (Bazel) which is just ironic for a C++ build system. Working with CMake is just painful. It is also just a generator, not a build system, its “language”, or whatever you would to call it, cannot be even compared to QML/JS of Qbs.

I also concur with others on the fact that Qbs was never promoted. With 2 devs it has reached really great progress over relatively short amount of time. Why do you even keep the qmake alive is mystery to me. Because it is used? It was your decision to keep it as default that makes people use it. If you were serious about it you could switch the default to Qbs ages ago in Qt Creator. Put it in examples, tutorials too. Just promote it in your own product – Qt – and it would gain momentum and I bet many people would happily abandon CMake in its favour. Because right now most people don’t even know it exists and are using CMake or qmake because of it.

It is like Internet Explorer web browser. The fact that it ships with Qt Creator (or Windows in case of IE) is not a virtue, it is pure coincidence and you have the complete power over it. But instead of making progress you tell us to go back in time and use legacy technologies with horrid user experience. Should we prepare to get back to Qt4 signal & slot syntax because many are still using it too?

mcu_by says:

this is very bad news, i really like qbs

Raphael says:

I’ve been using Qt for about 15 years with a commercial licence.
Very early we got ride of qmake to use cmake. But cmake is really a mess.
I managed to get ride of cmake by porting all our code base to Qbs in 2013. Never regretted this early decision.
I even ported Qbs to Yocto…

Qt made it clear that qmake will be replaced by Qbs. This is a big breach of trust to a commercial user.
I trusted Qt to make decision based on technical reasons.

No way I’ll go back to cmake mess. It would be like going back to cvs after using git.

Cristian Adam says:

THANK YOU !!! This is great news for C++ developers. Now the big players in C++ are / will be using CMake: LLVM, Boost, Qt.

This makes the integration of C++ libraries into one big project way easier. You can have the same build flags for all of them, you can have a static build, IPO/LTO build, and so on.

I think that when Qt Creator will have the same integration that Stephen Kelly has demonstrated in this video in 2016 https://youtu.be/BPgXuvPAl-8 people will not be hating CMake that much.

Damian says:

Thanks! I support that descision.
Just improve qmake and keep qmake syntax

Maurice Kalinowski Maurice Kalinowski says:

qmake is in maintenance mode since a while and will only receive critical updates. The idea never was to stay with qmake, but for legacy support.

Robert says:

Does this mean that cmake is going to be the only fully supported build system going forward?

HGH says:

Well, they did and called it qbs…

Andreas Bacher says:

Bad news for qbs users. Ported a large commercial projects to qbs because since qbs 1.10 it looked like that The Qt company is investing more resources into qbs and the qbs documentation. And we are realy happy with qbs as a build system. We have no problem that cmake will be the build system for Qt, that’s a decision of the Qt project itself.
Our issue is deprecating qbs and the support in QtCreator in one year. That means porting again large project to another build system. qmake -> qbs -> cmake.
We are very disappointed by this decision!

bnogal says:

Just make it easy to mix them.

It could be great to add CMAKE inside qmake.
or QMAKE inside CMAKE

Or QBS inside CMAKE….
You are just telling how to build the files… there should be freedom to mix them. I think it will end up with people switching to QBS slowly.

I choose my building system depending in the libraries and dependencies i am going to use. As is a pain to mix them.

Roman says:

We are are very disappointed with this decision. Our company has just bought many commercial Qt Embedded licenses and migrated a huge project QBS.
And now you say Qbs is dead…

Daniel says:

Whenever I touch CMake I hope for an alternative to arise soon. I estimate the personal effort that I put into writing working CMake configurations for projects as magnitudes to high and error prone. It is a pain in the ass and the results are often unconfortable and instable. I see this issue in many other libraries that use CMake too.
I just learned about Qbs and it hurts that people praise CMake now. I think Qbs was obviously not advertised enough until lately. It exactly satisfies my need to have a nice build system and I didn’t notice it for years. Although I looked for alternatives like “Premake”. A working build system with great dependencymanagement would be such a great enabler like when git replaced SVN. It drives young developers away from C++/Qt in favour of JavaScript/VisualStudio or other languages/IDEs with easy solutions like npm/NuGet/gradle.
I’d love to see it continued 🙂

NIkolai Marchenko says:

Some high profile people on the mailing list have already voiced their displeasure and at least one said their company will provide support for qt creator going forward because the don’t want to switch back.

Kervala says:

That’s a great news 🙂 CMake is very extensible and offer a lot of possibilities. Thanks !

stardust says:

Please give a chance to QBS! Our Team prefers QBS to cmake!

CESlater says:

I am another positive vote for CMake. CMake certainly has its warts but it also has it’s strengths:

– Support from major library players (as mentioned boost, protocol buffers,hdf)
– Support for more than 12 languages including FORTRAN and Cuda …. as a Mechanical Engineer FORTRAN is still important
– Support from package management software such a Conan (Conan.io)

Qt is certainly a nice framework and Qt Creator makes it accessible, but good CMake integration opens up MANY more opportunities.

I look forward to the day when I run Qt Creator and use Conan to link in Boost/HDF/VTK/OpenCascade.

HGH says:

I hoped that qbs will deprecate CMake but instead CMake deprecated qbs.

Currently I use CMake for all my personal projects.

Kai Dohmen says:

I was very shocked when I read this blockpost. Qbs is a very nice build system. I managed to build a project using the LUFA library with Qbs and it works nicely without any hacks or something. With other build system using LUFA is painfully. This is just one example of how good Qbs is.
I wonder why you deprecate Qbs. I mean the technical reasons. Maybe because you don’t want to port it from QtScript to QJSEngine? Please add another blog post explaining the reasons.

PS: I know one reason why you want to push CMake support instead of Qbs support (looking to KDE)

Raphael says:

Conan already supports Qbs.
Use use it to link with Boost and HDF libraries on windows platform.

I still don’t understand why spending all this effort creating a great tool and not making any effort to make known.
Why no example in QtCreator using it?

From release 1.10:
“Qbs (pronounced “Cubes”) is The Qt Company’s latest build tool, which aims to be the replacement for qmake in the Qt 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.”

What a waste of our customers money.

Pepos says:

Great, I just finished migrating project to QBS… You are a horrible company.

Fabrice says:

It seems a pragmatic decision since it is not the job of Qt do develop a build system. QMake is a pain. CMake is widely used and just work. Qt6 as an industrial framework need a proved build system. Also notice most KDE software uses CMake as a buildsystem.

HGH says:

Well, neither is the job of KitWare but they did it. And that cancer called CMake (which admittedly works well but is painful to use) spreads exactly as one and appears to be developed mainly by a single person.

Fabrice S says:

qmake and qbs are very Qt centric. While Qt must justify a community for a general tool.

CMake is largely used by C++ project, like KDE for example. And the drawbacks are known.

It’s a pragmatic decision at the end of 2018.

HGH says:

I use CMake often. It is horrible and wastes me a lot of time every time. It feels unlearnable. Not because it doesn’t work but because of its language and structure. The docs are difficult to read and even more difficult to remember.

I think that qbs stopped being Qt centric a long time ago.

John says:

There is nothing “Qt centric” in qbs (except dependency on Qt libs). QBS is the most generic build tool I ever have seen, it is very language agnostic, but the main focus is on C/C++ of course.

In a long run this a very bad decision for the whole C++ community, because we will stack with a tool which is very far from being optimal. Read the comments: most people who have tried qbs on real world projects don’t like to go back to any existing alternatives like CMake. This says something.

David says:

I vote for QBS 3.0, where you get everything right. Cmake with it’s makefile generation is 1980’s software.

Maybe in a 3.0 release, QBS could migrate away from QML and be a pure JavaScript technology which will help it cast a wider net.

Jason says:

No one likes autotools, but it’s what we have.
I would love for qmake to be more generalized to non-qt audiences so that we can save others from autohell.
Recently I found a project on git that was Qt, but only cmake. I was lost.

I think that if Qt creates better tools (and IMHO it already does) if we open it to other audiences, it will take off. Meaning that if there was a Qt distribution of just Qt build tools (qmake) that maybe had less Q’s (as to appeal to a wider audience) we woud gain influence as a project.

Maxim says:

Okay, fine, will you make cmake generator from qbs project for those who know qbs but don’t know cmake for project migration?

HGH says:

Just learn it. It took me a year to get comfortable with CMake. And every time when I don’t use it for a while I need to re-learn it 🙂 And even when I think that I know how to use it I find out that I have misread something and I use it wrong but as magical the CMake language is the broken code works.

Alexander says:

To leave completely clear and simple system and move to complex and confusing one. Believe, there should be a weighty reasons for that.

Maximilian says:

Still embarrassed.

Currently I’m also considering replacing QWidgets by Qml/QtQuick. HTML5 as Alternative just made a huge leap forward. Difficult to convince anyone of going for QML now, allthough it seems the much better technology.

Ivan says:

Commercial users that use QBS (and non-commercial too), please, list your companies/projects here https://docs.google.com/spreadsheets/d/1CwXx2F1zuATYY3GGOTkFgDB9jwMPghf6az_RVOnskfk/edit#gid=0

At least, we will know if it’s worth to continue developing QBS as open-source project (grrr, I just started contributing in it)

Fabrice S says:

I wonder to know why project managers in companies used an experimental build system (not used by Qt), while CMake do the job …

John says:

QBS is >7 years old, it is not in a beta state for a long time.

Michael says:

Because it was advertised by the Qt Company as the upcoming replacement of qmake for Qt 6. CMake was never even mentioned by the Qt Company as an option. Just recently during the build system for Qt 6 discussions it was brought up as one of the alternatives (Qt Development mailing list and Qt Summit). With Qbs being superior in every way (save for user base) many expected it to be confirmed for Qt 6 or at the very lest to replace qmake. It even started to accrue momentum this year with the reworked documentation and whatnot. And now we have Qbs abandoned, qmake still alive and kicking (causing widespread dismay) and CMake being considered de facto chosen build system bcause the only competitor was discarded. And CMake is really really hard to work with. I can hardly imagine how painful it will be to use for somethin so complex as Qt havinf first hand experience with it from far smaller and simpler projects.

Qt User says:

This decision is very disappointing. CMake is such a mess and besides QBS was another good usage scenario for QML.

Fred T. says:

Just a shame! CMake? Really?
CMake may be powerful, flexible, but learning it is just pain. And if it becomes the standard, it’s going to be though to attract people with it (there is already a problem finding C++ devs, so… I mean, look at the university curricula in North-America, it’s mostly Java).
I imagine that you think everybody works in gig teams where there is someone in charge of maintaining the build system, but what about the smaller teams? Or teams where there is only one person maintaining several projects in one department? (like me).
Even without a proper documentation (I mean, the qbs documentation clearly is missing a lot compared to the qmake one), I managed to use it. I hoped that qbs will replace qmake, and I was about to switch to it.
I just hope that this decision is not final, and that you would reconsider it.

Simon Parmenter says:

A technically superior build system, with the future potential of saving untold man hours of developer effort and saving of CPU cycles, thrown away.

This decision will be regretted.
As I regret it now.

Lilian says:

Finally… This is great news.
Let’s see how QtCreator’s support improves(currently you cannot add files for example or there is no autocompletion for source files when adding to a target – like in CLion).
We switched at work to CLion because of the great CMake support and in general it just works but our team does prefer the speed of QtCreator.

Bernhard says:

Qbs seemed to have made so much progress during the last year. And now this! This is really sad news, for Qt and C++ altogether.

While CMake might work, its syntax just sucks. And so does the code of CMake itself. Due to its disorganized software design and monolithic structure (all conveniently supported features, platforms, languages and tools are built-in, and their parameters are hardcoded rather than defined in .cmake files) CMake seems like a huge maintainane nightmare to me. Compare that to a language-agnostic, extensible-by-design tool with a nice declarative syntax, eating its own dogfood like Qbs… Then one really wonders why this promising technology must die.

Andreas says:

I love QBS since I was on the verge of implementing my own build system. I discovered QBS and it’s like 95% of what the ideal build system should look like.

To completely abandon it from the Qt project now is the worst decision you can make. It seems the Qt company is now driven by a short sighted management. Only because 90% of the people drive a fossil fuel powered car, does not mean you should abandon electrical cars.

First you start take this 3D Studio software from Nvidia, that ended up to require a full rewrite to make it a Qt tool. And now you complain that Qbs takes too many resources?

Please make a new survey! Please ask the open source community as well!

Alex says:

If you will use CMake as your main build system, than you will have to take more attention to the CMake support of QT Creator. Because if I use Modern CMake in these days, I speak from CMake from version 3.0 – its syntax is not as awful as many people mean – than QtCreator shows no source files in the project tree and shows a warning for all source files which says that they are not part of any project. And if I add new classes to my project, QCreator don’t recognises these files automatically like it does with qmake or qbs. But I think thats two parts of the same problem. QtCreator don’t supports modern CMake very well until now. With modern CMake I mean the target/poperty pattern which avoids to modify flags direktly.

Jean-Michaël Celerier says:

I think that you may encounter a bug somewhere else. I’m using modern cmake (always the last version) with QtC and all my files and projects show up correctly.

Alex says:

Yes, there was a bad CMake setting by myself. So I have looked dozens of CMake Tutorials to fix that. So I think QtCreator must integrate more auto settings for CMake like it is for Qbs or QMake. Its not very intuitiv if you must create a CMakeLists.txt from the ground up by yourself.

chezgi says:

bad decision.

Rolf Moholth says:

This is bad news for everyone . CMake is overly complex and low-level compared to QBS.
We are using Qt in a large commercial system and use QBS everywhere. It is a delight to work with!
Sad and dissapointed to see it go, but alas, nothing good lasts forever.
Event the Keppler Space Teleschope is going these days.

jeandet says:

Why not Meson?

I don’t see the benefit of CMake while close to qmake conceptually with an even worse syntax.

Except IDE support Meson is way better than CMake, being not Turing complete is one of the best design choices.
Features such as:
– builtin sanitizer support
– builtin coverage report generation
– cross compilation definition files
– Python like dictionaries
– Wrap dependency tool
Makes Meson really convenient to use.

Kevin Kofler says:

> Why not Meson?

As has been answered elsewhere, because it did not fulfill their requirements (such as working Qt Creator integration).

> I don’t see the benefit of CMake while close to qmake conceptually with an even worse syntax.

For simple projects, you indeed won’t notice the difference, but CMake has a lot more features than QMake, so for large projects, you can quickly get stuck (or have to introduce hacks and wrapper scripts, as in Qt itself) with QMake, whereas CMake works great for those, too (see KDE).

> Except IDE support Meson is way better than CMake,

I don’t see it being better technically. It follows much of the same design concepts, but has a lot fewer commands and shipped modules (so you can end up in a similar situation as with QMake, where Meson just won’t do what you need). It is also written in a slower programming language that requires an interpreter at runtime (Python).

The only reason Meson is a thing at all is really political: GNOME simply wanted to use something other than what KDE was using. Some lower-level projects in the graphics stack later picked it up driven by GNOME developers. I think that, for community reasons, Qt is much better off with the tool chosen by KDE (CMake) than with the one chosen by GNOME (Meson).

> being not Turing complete is one of the best design choices.

While recent versions of CMake are, in fact, Turing-complete, being Turing-complete is in no way a defining property of CMake. The only command that makes CMake Turing-complete at all is the rarely-used FUNCTION command (which supports recursion). You can write perfectly valid CMakeLists.txt files without using recursive FUNCTION or without using FUNCTION at all, and those files will always terminate and be decidable. So this is pretty much a red herring.

The Meson language is actually even more restrictive than not being Turing-complete (in particular, it does not allow everything CMake without FUNCTION allows), which limits the ways you can work around missing built-in commands.

Stéphane says:

What a pitty 🙁
I felt like qbs was killed before given a chance to win…

But asides from the feelings, I have technical questions:
– What about the main reason for the creation of qbs: Fast incremental Builds as explained in the first blog post on Qbs (http://blog.qt.io/blog/2012/02/15/introducing-qbs/) ? I switched to qbs a few month after that and the improvement on incremental builds is huge, what about getting back to qmake (i don’t know cmake on this aspect)… it’s a no-go !
– Is there any technical reason to stop it now ? It seems to me it has been way too long to develop, we should have had qbs to build Qt5. Is it also a question of return against investement ? Is there still so much work to do to get qbs as first class citizen ? So much that it won’t worth the price ?

I think people here need more information on what led to that decision, for the moment we feel betrayed…

Kai Dohmen says:

Qbs ist written using QtScript. But QtScript is deprecated for quite some time. Someone needs to rewrite Qbs to use QJsEngine or QtScript cannot be removed from Qt.
This could bei one big technical reason why they want to drop Qbs.

John says:

Very disappointing.
I am in the middle of switching my build system to Qbs (from plain make) in big project, which is multi-platform. After some fiddling and a learning curve, I am starting to enjoy the fruits the effort. Creating custom modules and products really simplifies things.
Qbs is a refreshing tool. I fill that some thing need more work, like documentation, examples, and maybe some design issues. I still find myself going the the cpp and qbs code to understand things.
From my point of view, I cannot evaluate the effort needed to bring Qbs to the state of first-class tool, but still, I urge you to reconsider your decision.

Zack says:

What did you learned about it? Why did QBS did not succeed like you expected?
“Throwing away” 6 years of work… One kind of lesson you must have learned. I would like to now.

NIkolai Marchenko says:

Since decision to deprecate QBS was largely made prematurely (imo) and with assumtion that no one sues it, we’ve started a list of project that use it currently to convince them otherwise.

Please list yours in here if you want QBS to continue: https://docs.google.com/spreadsheets/d/1CwXx2F1zuATYY3GGOTkFgDB9jwMPghf6az_RVOnskfk/edit#gid=0

@Nikolai: You can still continue to use Qbs, it will be supported for over a year now (until end of 2019). Most likely it continues to be usable long after that. Deprecation does not mean instant removal. It means that new projects should avoid using the deprecated functionality.

Michael says:

Building Qt has always been non-trivial effort. I could imagine it being far simpler and clearer with Qbs. In fact QtBase have Qbs project files already and they are rather nice and clean. With CMake it will be even worse than qmake. The fact that experienced Qt developers “got very far” building Qt with CMake is not really relevant, because the problem lies in that remaining part however small it is. Have you built Qt end-to-end with CMake or you just think it must be possible given how far you got? That remaining part will bite you hard. It will add ugliness and confusion and will require terrible hacks or help from Kitware or whatnot. The already complex CMakeLists.txt of Qt will become incomprehensible for regular Qt user similar to what it is now the build of Qt5. So in the Qt6 instead of going with pretty nice QML/JS modern build system anyone can use and understand we will have 90s spawn in form of CMake “language” with Qt specific magic sprinkled over it to describe and handle all that complexity Qt needs. I just hope Qbs will survive in spite of this…

Michael says:

This is very sad. I just recently converted one of my projects to Qbs, and it was the first time I was actually happy with a build system for C++.

I also share the opinion that Qbs was never given a chance. There was no observable effort to bring it to the attention of (C++) developers, at least not in any community I’m aware of.

Maybe there is some reconsideration with so many people voicing their disappointment. Let’s hope for the best.

In any case, I would also like to thank all the Qt developers for all the fantastic work they are doing!

Pavel says:

Qbs was introduced as the modern replacement of outdated qmake… I’ve complete porting of a project from qmake to qbs just 5 days ago… Aaaand it’s gone.
Why not 2 years ago, when it looks like an experimental feature in a separate repository? Why now, when It finally got a page in regular Qt documentation, when more people start to know about it, when examples were introduced, when people see updates, announcement and articles?
I suppose most of enterprise projects use only QWidget, not QML. Does that mean QML gonna be deprecated as well?

@Pavel: No plans to deprecate QML, but we have deprecated the old Qt Quick Controls 1 in favor of a new Qt Quick Controls 2. While deprecated, Qt Quick Controls 1 has not been removed. Also note that Qbs is not gone yet, so there is no immediate action needed. Qbs will stay supported for over a year (until end of 2019) and if there is interest in community for it we have nothing against keeping it usable. Some years ago we decided to move from Qt WebKit to Qt WebEngine, and while Qt WebKit is no longer officially supported it is still part of the Qt Project repositories and receives contributions from the community.

I can understand how you might think that the Qbs Manual was recently added, because the current version available is 1.12. However, it has been available at doc.qt.io since Qbs was first announced, on February 15th, 2012 (https://blog.qt.io/blog/2012/02/15/introducing-qbs/) . It was first available as a snapshot. It was added to the Qt documentation front page when Qbs 1.2.0 was released on May 5th, 2014 (https://blog.qt.io/blog/2014/05/05/qbs-1-2-0-released/).

Richard says:

The documentation made actually a big leap forward in spring 2018. That was the moment when I thought that the TQtC is pushing Qbs, finally. That was a wrong conclusion.

Michael says:

The Qbs docs were just a reference until recently. It was only earlier this year it has been completely reworked into mostly complete docs with examples, tutorials etc. I too struggled to get hang of it before the newer docs were available. So from the practical point of view its docs were just created. That it was not done earlier was a resources issue with about 3 people working on it one could hardly expect wonders. Nevertheless it just started to attract attention largely due to the updated docs and regular blogs here in spite of complete lack of propagation from Qt Company. Only to be killed off based on the alleged 2017 survey.

Eli says:

@QtCompany Can we have an open survey? This is a ridiculous decision using this horrible outdated build system 🙁

stardust says:


Raphael says:


Kai Dohmen says:


Pavel (hkarel) says:


SomeoneWhoCares says:


Michael says:


Uwe Kindler says:


Dmitry Volosnykh says:


hasardel says:


Michał says:


Francesco Lamonica says:

+1 (commercial customer)

FuQiang says:


M.N. says:

Really?!?!?! Cmake is absolutely terrible!! I was so glad when my company ported everything over to qbs….guess that was a waste of resources seeing as there is not intent to even maintain it. So glad we wasted the resources pursuing this. If you are going to cmake there’s really not a lot stopping me from dropping qt products all together, perhaps I’ll be looking into other IDE’s and build systems.

@M.N.: You can still continue to use Qbs, it is supported for over a year now (until end of 2019). Most likely it continues to be usable long after that. Deprecation does not mean removal. It means that new projects should avoid using the deprecated functionality.

Philip S says:

My company has invested a serious amount of time build systems over the years. We’ve used QMake, CMake and QBS. QBS is by far the easiest one to used and it’s flexible. I love being able to inherit build components using QML and use them in multiple projects. It’s also fast and extendable. We have qbs building fortran code, running testcase, package creation, and uploading builds to an ftp server. I’m not sure why Qt Company wants to use CMake, a painful dinosaur from 2000. Our build system progression has gone like this: QMake / Makefile -> CMake -> QBS. Now I guess it’s time to go back to stone ages with CMake. Overall this is just a bad decision. Another thing that bothers me is that, Qt Company has be showing off QBS as the Qt build system, even as recently as last year’s blog post. They even encouraged people to use it! Now it’s being deprecated. My feeling now is it’s hard to know what technologies adopted and what ignore from the Qt Company. Judge by the responses on this blog post, it seems like QBS is just gaining momentum.

I.F. says:

Very sad to see this. In a twenty-five year software development career, Qbs is the first build system I have enjoyed using. The build files are easy to read. The performance for large sets of libraries and applications is superb. Incremental builds are very fast. I very much hope Qbs continues somehow.

Kevin Kofler says:

I appreciate this decision. CMake is a mature, powerful build system used by dozens of Free Software projects, and already very popular in Qt circles since its adoption by KDE. It is packaged in almost all GNU/Linux distributions out there, and binaries for the main proprietary operating systems are available from CMake/Kitware themselves. And it is written in C++ (just like Qt itself), so it does not introduce heavy runtime requirements such as Java or Python.

Qbs was pretty much reinventing the wheel and, being itself written in Qt, creating a bootstrapping nightmare. (CMake does not require Qt except for the optional GUI, so there is no such circular dependency there.) So, from a practical technical standpoint, CMake is the better choice.

Christoph Cullmann says:

I can second that.

Normally you need to fight with X build systems if you develop your application and need to compile most dependencies yourself for bundling.
To have X+1 build systems doesn’t make that easier, even if the one extra system is a bit nicer.

qbs is around since >> 5 years and didn’t attract the critical mass to be used by any larger open source C++/… library out there.

Perhaps it was not advertised enough, perhaps not enough money was spend, who knows, but if it would be light-years better, I would have assumed more projects jump on the wagon and more people contribute.

But just compare:




Perhaps CMake is a real pain for some people, but at least it has some drive and a large user base of people actually be able to help out.

Michał says:

Aye comparing… With much less development effort Qbs is better than CMake. Quite amazing!

HGH says:

COBOL is mature. Why was it replaced?

Jakub says:

I understand it was tough decision but I totally get it. I was considering switching to QBS with my projects, but keeping qmake as default in QtCreator suggested me that QBS is still experimental.

On one hand, most of the IDEs use CMake the same as for games we use Windows: lot of people hates it but it’s powerful and widely spread, hence it won’t die that quick. CMake looks like more sense option as I’m pretty sure there wouldn’t be any support for QBS in CLion, Eclipse and other IDEs – but we already knew that from day 0 of QBS development.
QBS is open source software released under LGPL, so if someone (community?) wants to use and improve it, there are no obstacles.

On the other hand there is community, devs, clients…a lot of people started using QBS and it’s been deprecated in really early stage, so it really strain our trust in you – Qt Company. Devs will be careful in the future before trying something you’ll release. Why? Imagine that someone plans the huge project with a lifetime for 10y or so, and will be considering Qt, Qt 3dStudio and other recently released components. Then this situation will be mentioned on the meeting: do we trust Qt Company? Won’t they change their mind in the future and stop support for the particular tool/component?

I believe that it wasn’t easy decision to make and it’s almost impossible to make everyone happy. Just please, ask your community in the future and not the mystery subgroup of commercial clients. Be transparent, be fair.

IMO QBS should replace QMake as soon as possible because QMAKE is far from perfect. QBS could be an excellent example, that QML is great language not only for UI.

Alexey says:

OMG! NOOooo.
You can just make something helpers for migrate from cmake to QBS. For example create Qbs module for include cmake subprojects, qbs generator for cmake, documentation etc. Cmake – Ancient, scary dinosaur !

Kai Dohmen says:

Asking your commercial license holders if what build system they use just to deprecate Qbs is pathetic. Why should big companies even use Qbs? They dont know if you will deprecate the “new technology” Qbs some time so they stick to the de facto standard (CMake) or your own standard (qmake). So the surveys outcome was highly predictable!
Since the Qt wants to be open source it should ask the open source community! There are the developers which take the risk using new technologies like Qbs. In a company changing the build system cost money so why should they use a build system which future is unclear?

These aspects make me assume that someone in the Qt Company decided to deprecate Qbs and the survey is just an excuse to justify that decision.

mx says:

Asking your commercial license holders if what build system they use.
In discussion Qt 6 buildsystem support requirements: “3) Community support.”
Well, the easy way.

Meanwhile, example for gtk + meson buildsystem with it wrapping feature:

and compare this with “Building Qt 5 from Git”

Mike says:

The decision to stop QBS after such a long time; to have it already built into the Qt Creator; to have the people at every Qt World Summit convinced of it; … is just absurd. Besides, it’s another great use case for QML. Did the commercial customers of the Qt Company even know what they were voting for? I myself have ported a large project to QBS and am simply enthusiastic about the system. It’s a big mistake to shut down the system and it will take away more confidence in your technologies. Your development towards Automotive seems to me to be an increasing risk for other applications of Qt.

dbskcnc says:

well, sad for qbs,
i think the best solution is decouple qbs from qt company, move it to github and let the community do their decision

@dbskcnc: Qbs is already open-source. Has been from the beginning. Developed under the Qt Project. Everyone is able develop it further, but very few have done that except for Qt employees. As I said in the blog post, we are happy to continue providing the environment to continue developing Qbs and can help in reviews etc. So this is a good opportunity for community to pick up – as we are still working on Qbs towards the April release and supporting it throughout 2019. Qbs is found at: https://codereview.qt-project.org/#/admin/projects/qbs/qbs and information about the Qt Project and how to contribute at: https://wiki.qt.io/Qt_Contribution_Guidelines.

Richard says:

Tuukka, maybe we live in different worlds? I do not see an active developer community, there are no structures, no processes, no community feeling. The Qt Company always developed and treated Qbs like its own product. Posting a a headline “Deprecation of Qbs” reflects that thinking very well. Yes, single contributions were always possible and accepted.

Investing 7(?) years into Qbs and then suddenly chunking it all down without even trying to nurture a healthy community doesn’t look very good to me. I am not questioning the company’s decision to stop pushing Qbs, but I am questioning the way how you stopped and communicated it. That leaves very little room for “the community” to take over.

@Richard: Deprecation does not mean something stops working or is removed. As I wrote it the blog post Qbs will be supported until end of 2019, and we are still working to make a feature release of it in April. As a user, you can continue using it just like before – but as it is deprecated it is recommended not to start new major things with it. We are well aware that outside of The Qt Company, very few others have contributed to Qbs. But it is possible to start contributing now. Qbs is fully open-source. Has been from the beginning. Developed under the Qt Project. Qbs is found at: https://codereview.qt-project.org/#/admin/projects/qbs/qbs and information about the Qt Project & how to contribute at: https://wiki.qt.io/Qt_Contribution_Guidelines. The development processes, governance model and structure of the Qt Project are explained here: https://wiki.qt.io/The_Qt_Governance_Model.

Richard says:

@Tuuka, I am aware of those pages and I have read your blog post, but thanks for the reminder. I think you are not getting my point and it appears that we have a very different understanding of how to run an open source project. I cannot see how the Qbs project currently meets the governance model of the Qt project except for the code review part. https://wiki.qt.io/The_Qt_Governance_Model#Decision-making_process

Can you?

@Richard: To me the governance model applies. There is no problem to further develop Qbs within the Qt Project, if there are people who want to do it. If the functionality becomes actively developed by the community, there is no need to remove it e.g. from Qt Creator. The current assumption is that Qbs will be supported commercially until the end of 2019 (under the Standard Support SLA, via the Qt Account), thus status is marked as Deprecated so that those using are aware of possible issues going forward (after support ends).

Ola says:

What my colleagues and I read from the headline “Deprecation of Qbs” is that it failed completely and we should not use it for new projects. The headline for this blog (and the similar email on the mailing list) is very unfortunate. If people did not already try Qbs before you really made sure they won’t after this.

I wish you’d put out some new blog article clarifying this. It does not matter what you think “deprecation” means, if the people that read you headline understand it differently than you.

My experience is that more and more started adopting Qbs during the last 6 months or so, it has just begun gaining traction.

Marcel Charlebois says:

Wow. If The Qt Company does not reconsider deprecation of Qbs after getting all this feedback, that will clearly indicate their attitude towards Qt users.

Marcel: Note that Qbs is fully open-source. Has been from the beginning. Developed under the Qt Project. Everyone is able develop it further, but very few have done that except for Qt employees. As I said in the blog post, we are happy to continue providing the environment to continue developing Qbs and can help in reviews etc. So this is a good opportunity for community to pick up – as we are still working on Qbs towards the April release and supporting it throughout 2019. Qbs is found at: https://codereview.qt-project.org/#/admin/projects/qbs/qbs and information about the Qt Project and how to contribute at: https://wiki.qt.io/Qt_Contribution_Guidelines.

BogDan Vatra says:

I think you misunderstood the point of all these posts :).

The Qt Company made a promise. Based on that promise, these people ported their projects (from small to huge) on QBS, preparing them for the *future*. Now you come and say there is no future for QBS, and that’s why all these people are upset.
Saying that QBS is open source and if they like it that much they can take the srcs and continue the work on it, you just put more oil on fire, and it just makes these people more upset ;-).

I’m quite sure that you’ll not change your mind again, but I’m curious about a few things:
– first thing is how did you evaluate CMake?
I’m asking because in this very moment cmake:
* it doesn’t support all Qt tier1 platforms (i.e. iOS, intergity)
* it doesn’t even have all qmake fatures (e.g. in 2018 it still doesn’t have precompiled headers, which will slowdown the build time)
* it can’t compile for multiple platforms at once (QBS can compile android arm & arm64 at once and package both of them in the same apk)

– last but not least, I know (some) of the QBS internals and I know the mistakes that were done, but instead to deprecate the product, why didn’t you “deprecate” some of the people that were working on it, instead to deprecate QBS?

For me and for all these upset people going back to CMake from QBS is like going back to MFC from Qt … No, I’m not joking, it’s that bad!

@Bogdan: I also see that is quite unfortunate that despite the brainpower put into Qbs during the past 7 years we are not in a point where we initially aimed for. I am not blaming anyone, we did what we could. Today Qbs works quite nicely for Qt applications and the effort to keep it that way is not large – especially as we will support it for the whole next year. I very much hope that there are interested people in the Qt community to take Qbs forward and keep it an option for building Qt applications. Being able to build Qt itself is not necessary (that is a bigger tasks). What comes to “a promise”, this is exactly the reason why we wanted to communicate early the decision not to make Qbs the future build system of Qt. It was our aim in the beginning, but we saw that getting the wider C++ user community to move on top of Qbs is not happening. Even if we added a lot more resources, it still would not happen.

John says:

>we saw that getting the wider C++ user community to move on top of Qbs is not happening. Even if we added a lot more resources, it still would not happen.

I would say that you are wrong here, people do move to QBS because they see power and elegance of this tool. Just time is needed. Almost everyone who have tried QBS prefers it to CMake.

HGH says:

You certainly didn’t try to promote qbs. It doesn’t have a dedicated site. It doesn’t have OK documentation and samples.
It always felt like a side, hobby project by some Qt employee

HGH says:

In that case please add support CMakeSettings.json configuration file used by Visual Studio 2017 for easier cross-platform and cross-ide support.

Thorbjørn Lindeijer says:

I’ve been excited about Qbs ever since I first saw it demonstrated while I was still working for Nokia back in 2011, and I’ve been happily using it since 2014 (most notably for Tiled). I’ve also used CMake for multiple hobby projects, but on such projects we always needed an “expert” who massaged the magic incantations into working builds, quite similar to autotools. Long story short: I consider this a really bad decision and will personally never go back to qmake / cmake.

Also, like others said, it is no wonder your customers are still using qmake / cmake! It will take more time for them to discover the benefits of Qbs. When you’d listen only to those who already tried it, the numbers will look very different!

Cyril Jacquet says:

I thought Qbs was part of the future of Qt, so I ported my project to Qbs recently. I only succeeded thanks to the updated documentation. I’m still struggling with the Android part of Qbs and building a Qbs project for Flatpak, but I’m satisfied for now. It just works and I can concentrate on writing code. Despite it being deprecated, I’ll keep using it.

I read somewhere that only two developers from the Qt Company are working on it. They did a beautiful job. Maybe it’s time for the community to compensate for their reassignment ? I’m no expert, yet I’m looking into contributing where I could, with examples or translations. Everyone can help and make Qbs live !

Aliaksei Stratsilatau says:

Very bad news. We are using QBS to build a complex multi platform project, with multiple architectures (cross-compilation, etc). It also builds firmware packages for our hardware devices and documentation sites. Everything works out-of the box and very easy to setup and maintain. Anything is possible to expand and customize with just a few lines of QML/JS code. We’ve converted all old cmake-based projects to qbs very easy and in short time, and the outdated cmake (wheelchair of slow and ancient make) is not even close to the current qbs build system capacity and potential. The worst decision ever of Qt, sorry. Definitely, we will will continue to use QBS, even if there would be no support from Qt at all, but will never return back in time.

Leena Miettinen Leena Miettinen says:

It would be really helpful if you could describe the porting process and give some pointers based on your experiences as comments to https://bugreports.qt.io/browse/QBS-1177.

d3fault says:

It makes sense to me that a framework for building software (Qt) contains a software building system (Qbs).

Qt sets new standards, doesn’t rely on existing ones. std c++ is decades behind Qt.

CMake is to Qbs what Gtk/C is to Qt/C++. CMake works and has a large user base, but is overly verbose and not elegant.

I think it’s rather rude to go and deprecate Qbs without even giving the community the opportunity to maintain it. Deprecated is a strong word, who would use software which is “planned for deletion”? As others have said, Qbs was never given a real chance. Would have been much better PR to mark Qbs as “Done” or “Maintained by Community”, instead you declare intent to delete it. Qbs is already functional and could easily stay up-to-date with new compilers/flags solely from incremental community contributions. But instead you just up and decide (without consulting the open source community) to mark it for deletion, scaring everyone away from it for good. Qt a meritocratic community project? This decision wasn’t that.

I just hope these Qbs developers that now have their time freed up aren’t sent to work on something similarly wheel-reinventing such as Python/JavaScript.

I’m not too upset over this Qbs removal decision, but much more upset with the way it was handled: Dictator Tuukka has decreed Qbs no more, and the comunity HALF of the Qt project has no say in the matter. (Yes I saw the fine print saying “community is welcome to maintain it”, but you’ve already damaged Qbs project significantly by deprecating (declaring intent to delete) it).

Cristián Cristián says:

Nobody want to delete it, from the official announcement on the Development mailing list you can read the following statement:
“Qbs is open source and if someone wants to take over and develop it further let us know as well”
The repository will remain as long as the Qt project community wants it.
This announcement is that TQtC will no longer officially maintain the Qbs project.
There is a really long discussion on the mailing list, you can contribute that discussion too.

HGH says:

BTW Qt Creator’s support for CMake is rather poor. So poor that when I ported our big project to CMake with Qt Creator in mind I rather quickly switched to VS Code.

@HGH: We are going to improve the CMake integration of Qt Creator as well.

Alexey says:

Will Android and iOs support for QtCreator be done before April 2019?

Tino Pyssysalo Tino Pyssysalo says:

I’d like to bring Qt product management (PM) view to the discussion. There has been much more behind the decision making than the customer survey, which is frequently mentioned in the comments.
One of the PM tasks is to visit Qt customers to understand what customers want and need to run their business, based on Qt. In numerous customer meetings, we heard that customers prefer having a good support for their existing SW projects/products. Majority of customers mentioned that seamless integration to their CMake projects is more important than a custom build system.
After listening to our customers’ voice, we turned into the community. Some of you may remember the Qbs usage survey, I conducted in Qbs mailing list in June. I asked in which kind of projects developers use Qbs. The survey did not get a lot of interest, as only 13 projects were reported, 4 pet projects and 9 real projects. Qbs was considered superior to many other build systems in terms of performance, scalability, syntax, but there were also concerns about missing features, such as CMake generators, embedded toolchain support and so on. The PM did not make a conclusion that Qbs is not used much, but rather we were more convinced that Qbs is not mature. Serious development effort would be needed to make it ready or we could use the effort to build support for another build system.
I hope this will comment would help understanding the decision from the product management point of view.

Alexey says:

Customers are always conservative. 90% real projects are not using C++11 (14 etc), they still using java 1.4 instead new versions, Carl !
“Qbs is not mature” ? So make it mature!! More documentations, more generators, more tutorials for migrate from cmake! Provide the possibility to add cmake project as submodule etc.

HGH says:

Personally I haven’t seen that survey.

Richard says:

Thanks for explaining it from a PM view. I remember the “survey” well. Why did You not also post it in this blog as well to reach a wider audience?

What I am particularly upset about is that You did not come back to the community with further information as I kindly requested via eMail: decision transparency, roadmap, etc.. Just a little bit more communication about the TQtC’s thoughts and a plan how to turn Qbs from a 99% employee-driven into a real community project could have made a huge difference. Instead: silence and then the atomic bomb “Deprecation of Qbs”.

It has happened only recently that the CTO posted a constructive eMail about going forward on the Qbs mailing list. Finally. http://lists.qt-project.org/pipermail/qbs/2018-November/002275.html

Why can’t the TQtC not communicate that way upfront?

HGH says:

Just a side note: Qbs is deprecated in favor of CMake but yet there are no documented improvements of CMake support in Qt Creator 4.8 but one qbs related.

Qt should really bring a gazillion improvements in CMake support to Qt Creator starting from Qt Creator 4.9 (immediately)!

@HGH: This is the goal, yes. Of course it will take more time than just a few months (Creator 4.9 coming in April). But over time we expect the CMake support both in Qt and Creator to improve.

HGH says:

Thanx! Visual Studio 2017 supports CMakeSettings.json – which enables easy portable platform configuration, which you can actually commit to VCS. Please consider supporting this file format. It is not perfect but it is much better than what’s implemented in Qt Creator right now. It will also allow to easily switch between Qt Creator and Visual Studio for CMake projects.

Paro says:

Qbs seems for me the right compiler for c++. It ligns up the philosophy of c++ being fast, flexible and powerful.
Qt should still make it number one, with a cmake generator and importer. It saves compile time, computer power and needs less time to maintain. I cant imagine any programmer wouldnt love it.

It feels like many companies would profit by porting to qbs and never regret it (SAVE a lot of MONEY, be happy and start to contribute to qbs). We need just more examples and a finished documentation. If qbs was number one in Qt creator, everybody would have seen how good it is. Its also easy to use, even if you don’t have any idea about it, if you only see some examples.

You should give Qbs two years more love, without making it deprecated, and finish it first, then promote it.
At least all Qt examples should have a *.qbs file and Android integration should be finished. Without this effort, you cant say, people don’t want or love it. I just think you did a great tool, as usual, and it’s worth sticking up longer for it.

Paro says:

Somehow I wrote “compiler” instead of “build tool”.

Commenting closed.

Get started today with Qt Download now