To make, or not to make - QMake and beyond: Redux

The previous blog entry yesterday spawned so many sizable comments, that I felt they couldn't be simply replied to in comments. So, here are some replies and comments to your comments, which you may comment on again :-)

Many: "Have you considered the <insert favorite here> build system?"

Yes, we have.
Any Java-based system is automatically /ignored due to the vast overhead of running such a system, and the fact that we would then need a Java VM running on all the systems we support. A build system needs to be fast, and fairly lean.

We're not really considering the autotools.

Max: "CMake gets a lot of “wow! it’s great!” comments, but I could write several blog posts about how it is in fact merely mediocre. I guess you guys agree since you are not considering it."

This is incorrect. We have not said nor implied that we are disregarding CMake. CMake might not current fulfill our complete wishlist, but we are of course still considering it. In fact, we initiated discussions with KitWare (the guys behind CMake) weeks before this blog post, to see if our wishes are unitable with their plans for CMake. These discussions are still ongoing. In fact, Bill Hoffman (CTO & Vice President of KitWare) is currently at DevDays in Munich, where these discussions will continue.

nathan: "I think the idea of using JavaScript has all the many advantages"
Sylvain: "Javascript + JSON is really good, please go for it…"
Damien Arthur: "a build tool based on json would be sweet!"
Adam Higerd: "I like the idea of using ECMAScript / JSON notation. It’s simple and not overly verbose, but expressive enough to handle non-trivial setups."
mariuz: "I would choose javascript or minimal python (waf like)"
spinynorman: "Please don’t base any replacement on JavaScript."..."your core audience is developers familiar with desktop rather than web languages. I’d much rather have it Python based than JavaScript."
Tim: "I think IDE integration is the most important factor to consider, and one that you can’t do right if your build file is a script."

After having thought about build systems a lot, we tend to like the idea of JavaScript as the build language. The reasons are several:
1) Javascript lets you use both an imperative language, and a subset declarative syntax (JSON).
This is great for supporting IDEs, since you can say that a project is primarily defined in the declarative syntax, while still support more complex builds using a full imperative language. The IDE would then only support modifying the JSON of the project, so support changing compiler flags, defines, adding and removing files on various platforms etc, and for the non-declarative parts it could drop you out in a tab-completed syntax-highlighted editor with easy access to documentation ;)
2) No need to rely on 3rd party
JavaScriptCore can be bootstrapped into the product, so there's no need for a 3rd party distribution. That also enables us more to structure the language usage, as you wouldn't expose a boat load of libraries by default, which you would have with for example Python.
3) Native speed on many platforms
JavaScriptCore will compile the scripts into native code on many platforms, and increasing, so the script execution is fast.
4) Good debugging tools for JavaScript
JavaScript has plenty of debuggers readily available for it, so you can debug the whole build process from within the IDE, for example.
5) Solid user base, and growing
The World Wide Web usage of JavaScript is growing at tremendous pace. QMLs scripting language is JavaScript. So, on a team there will always be someone who already knows the language. This makes build system maintenance easier for both us and our users.

Peter: "It isn’t too hard to use CMake with QtScript, see http://sourceforge.net/projects/cmakescript/"
A hello world looks like this:

project("hello")
// this starts the debugger
 // Qt 4.5 needed
 debugger
var name = "Hello";
add_library (name, "hello.cxx")
 

This is a very neat proof of concept, and I could definitely consider CMake with a JavaScript language. However, unless you also start changing some of the internals to make use of the language more effectively, then all you have a new language used in the same way as before, like the add_library() function call above. If the internals were modified to allow for the the JSON construct of the project, then we're talking! This project is great, but at the current state, not much more than what we had with QMake + JavaScript, which we had before. (And I'm not sure KitWare would want to integrate the whole QtScript module into CMake ;-) )

DAVIDB: "Cmake - its good enough for KDE which handles like a billion lines of code in hundreds if not thousands of projects. It’s been around a while and has proven to be a very good cross platform configuration tool."

Several features needed implementation before the KDE project could use CMake; and several more would be needed to properly support Qt. It's not just about the missing features, but also about language. We like how easy QMake projects are for medium projects, although it can get ugly when you get into the medium-to-complicated projects. It's also very quick to get started with. Often you can just run qmake -project in your project directory, and you have a .pro file which gets you most of the way, if not all.
You also have to consider all the customers that Qt has, and will have as the various phone ports move along. What we decide on will ultimately push them to switch at some point, although we will of course maintain QMake for some time.

Coder: "Why not take an existing Open Source cross-platform build system and contribute to it."

If we find a project which maps nicely with wishlist and requirements we have, of course this is what we will do. We don't want re-invent a wheel, if we can avoid it. However, we do have strong reasons for not just jumping on any of the ones discussed in their current state; and that's also why we're reaching out, to see what ya'll think about the various tools out there, and QMake of course.

spinynorman: "whatever you do please provide a painless upgrade path - a way to import QMake .pro files into the new system"

The users are always our primary concern, and we would of course do everything we can to assist in the transition. Just like Qt 4 has the Qt3Support, maybe the new tool would have a QMake front-end alternative? It's not impossible.

spinynorman: "please don’t have any hidden behaviors like special include or library paths (such as the libary paths that QMake itself decides to add to Makefiles)."

I fear you might be using QMake in the incorrect way if it's adding library paths which you don't want into the Makefiles.
For example, if you wish to use QMake on non-Qt projects, you should do CONFIG-=qt.

spinynorman + many: "Can’t QMake be fixed rather than replaced?"

Possibly. However, it would take considerable efforts to switch out the internals while keeping backwards compatibility, and at the current state of the QMake autotests I wouldn't dare it. Though, I guess it would be doable if enough people consider it a much better alternative than something new. One thing is then, how do we fix up the language mistakes without destroying too many projects? Bring the QtScript module back into QMake?

Holger Schurig: "If you consider using your own tool, make it a library. So that it’s easyly integratable into some IDE."

If we decide on writing our own, that would be the idea, yes. The library would contain the whole DAG, have functions to manipulate the project JSONs, and the IDE could walk the invalidated DAG nodes, both to compile them, and to update the code completer.

Holger Schurig: "QMake currently has several generators, e.g. unix (make) or windows (nmake). Maybe it can gain a qbuilder (or whatever the new name will be) generator. That would allow you to use qmake to convert a qmake-project into a qbuilder-project."

That's a novel idea. Only problem is that much of the project is "lost in translation". Once the front-end parses it, much of the information is thrown away (system checks, conditions, loops etc), so the information the back-end sees is only valid for that one particular configuration.

Reed: "Jam (Boost Jam or Perforce) are pretty good"

Read this article: http://gamesfromwithin.com/the-quest-for-the-perfect-build-system-part-2

Cliff: "Ecmascript-Syntax is better than any strange language but it won’t fully fix the problem for IDEs in my eyes. Should the IDE evaluate the code?"

As mentioned above, if the build system was libified, the IDE would contain the whole build system logic, parser and DAG. So, it easily could reparse the project file if need be, and replace that project branch in the DAG. The DAG walkers would then take care to only rebuild the invalid nodes.

Craig Ringer: "CMake looks nice … at first. Like most build systems, it turns out to have some huge, ugly warts."

Any build system will in someones eyes have these "ugly warts". QMake certainly has a few of them. How we deal with them (reporting/complaining, sending patches) and how the team maintaining the tool handles them is key. It's OK if a tool has some warts as long as a) you have possible work arounds, b) you can live it the issue, and/or c) the team is actively trying to fix these issues. I'm certain KitWare doesn't like warts in their products, and are actively trying to fix them. :-)

Craig Ringer: (about CMake): "I’ve had to copy almost every standard Find module I use into my source tree and modify it to handle one or more basic issues - improper caching of negative results, failure to handle debug library linkage on win32, failure to handle spaces in paths, etc."

..And I assume you've contributed these patches back to KitWare, right?

Craig Scott: "Cross-compiling: I much prefer to compile on the platform itself. Once you have to integrate third party packages that need to be installed to supply bits of the build (eg libraries, headers, etc.), trying to set up cross-compiling gets too hard."

Unfortunately, this is a reality which we (Qt) have to live with, increasingly. When we start targeting even more embedded systems, phones etc, we often have to do mixed cross-compilation. It's good that not too many have to do this though :-)

Uwe: "For me it would be more important to see a better documentation of the existing qmake, than a new build environment."
Florian: "I strongly vote for rewritting QMake and for staying backward compatible (!). That mainly means that you need to write a good unit test for the existing QMake functionality and keep that running while refactoring."..."In our company we have thousands of QMake profiles and it would really be a bad decision for us if you stop QMake!"

QMake certainly has a lot of undocumented features, and should be better documented. However, our organization is hitting the limits of its capabilities and maintainability, so we find it hard to continue at the current state. Either we seriously renovate QMake, by fixing its internals and shape up the language, or we move over to another tool and try to shape up that one. I guess most QMake users today would want us to do the former, but the question is then, would it require too many resources to get there; and in what time perspective?

Per: "Allow the easy and familiar ./configure interface to switches with integrated documentation."

This has been one of the topics of discussion with KitWare, yes.

Chris: "How about a XML-based approach, like Ant?"

XML is too verbose, and impossible to maintain by hand. Yes, many of our users don't use a GUI for development, and would hate to maintain XML files for building.

cartman: "http://code.google.com/p/gyp/ might be the answer to all your problems"

It's got the JSON part, yes, but a bit young and feature-lacking of a project if we decide to go with something established.

Sebastian: "Long ago, I looked at QMake and I believe at that time it wasn’t able to create full-blown VS project files that allowed to tune all usual settings from within the IDE, but some crippled wrapper projects that just called nmake and lacked the usual settings."

Just had to respond to this one, since I wrote the whole vcproj/sln generator: QMake never ever created a nmake wrapper for VS project files. The first iteration of the vcproj generator parsed all known options at the time, and placed them mostly correctly in the vcproj format.

QtFan: "I’m curious, when you are talking about changing/replacing QMake, are there any thoughts about changing/extending MOC !?"

Moc is a different discussion altogether. And no, we're not planning to change Moc. Extending it, maybe. Give us a detailed use-case, and we'll talk about it.

Florian: "I think if you would create a new tool, we would NOT use it in our company and change to CMake instead, because CMake will never go away."

There's no reason why QMake should go away either. It's Open-Source after all.

gwright: "Personally, I think qmake is great. However, there is one huge flaw with it which is a showstopper for at least me"..."he makefile generator backends for qmake are paired with specific linker versions"

Yes, this is somewhat true. However, it's not impossible to fix, and we have a developer internally which is trying to cross-compile Qt for Windows on his Linux box using MinGW, and run that result directly from his VMWare image. The applications now run, but missing some graphics :)

Ok, that was some of my comments to your comments. Keep the comment flowing, we need to know your opinions!

Thanks!