[Qt5-feedback] Qt5's qmake

[Craig.Scott at csiro.au]

Picking one of the emails to reply to somewhat at random to provide some real world experience around this.... ;)

Our code base is large (approaching 1 million LOC, for what that metric is worth) and multi-language (C, C++, Fortran90 and occasionally other stuff). We have to incorporate some third party packages with their own build systems as part of the build and we need to support Windows, Linux and Mac. Our builds contain hundreds of targets (let's not even count the tests). We started in the Qt3 days and we continue using more or less the latest Qt4 releases now. I also maintain a set of patches to allow the Qt 4 source to be built with LSB compilers under linux (I mention this primarily to highlight that we also need to use something other than the default compiler on some platforms). Our team is a mix of software engineers and scientists who are self-taught programmers with low tolerance for complicated build systems.

We've adopted a number of build systems over the years in attempts to find something that can cope with the size and complexity of that described above. Here's what we've found (in the order we have used them):

autotools:
Unix only, dropped it when we added support for Windows. Plenty of other problems I won't go into since it's not really a relevant choice for the discussion here.

scons:
Very flexible, can do just about anything you want, but adds a dependency on python which caused some problems - especially when they did the break for Python 3.0. Also had some minor problems with non-English language devs (again related to use of python). The main reason we dropped it though is that it just couldn't cope with the size of the builds. It would sit and think for 30 seconds or so before it even started compiling things. It basically has to do a configure step every time you build. Self-taught developers found the project files a bit confronting and tended not to delve into them, and the delay on starting compile was driving some of them to use their own private make files. Getting patches/fixes into new releases (especially for Qt4 in the early days) was a hit and miss affair. Years after we moved on from SCons, I'm still getting the occasional email about an issue that still hasn't been fixed. I got tired of having to fix all our Qt4-related issues myself and maintaining and updating patches for each release. In summary: great flexibility, too slow, a bit of a hassle to maintain.

qmake:
Easy to get started, but quickly hit its limitations for large code bases. The lack of support for languages other than C/C++ meant we had to come up with our own for Fortan90 (which we did, but it wasn't great - dependencies were a pain to get right). We found we ended up using a bunch of "undocumented" features to do what we needed. Had some hassles with getting qmake to play nice with the LSB compilers too. Responses to bug reports/patches was dependent on whether or not many others were likely to be affected by the same issues, but at least they were generally acknowledged in a timely manner. Ultimately though, having to support other languages and the use of undocumented features drove us to look for another alternative.

cmake:
The syntax of project files was a bit odd, but newer versions were a bit more relaxed in its rules which helps. The GUI and ncurses tools help less technical users who, while they still don't really get into the project files, they do feel brave enough to tinker around with a few things (compiler flags, etc.). The ability to turn things on and off with a checkbox in the GUI is helpful (enable OpenMP, turn off building docs, etc.). Support for multiple languages is better than any of the other tools we tried, although we still add our own customisations over the stock standard compiler setups CMake provides (but these are generally easier to maintain than for previous tools). CMake seems to cope well with the size and complexity of our projects, with fewer issues relating to inter-target dependencies. The "make test" feature is particularly handy and is something the other build systems didn't have built in. We've also recently started using the related CPack functionality too, although the documentation for this is very fragmented (collected from various wiki's) and needs a considerable overhaul. We intend to look into CDash soon as well since it looks like that will integrate nicely. The response to bugs and patches has been fantastic - kudos to Brad King and others at Kitware for helping make CMake build with LSB compilers in a matter of weeks and having all patches in the next release that came out (2.8.4). We now run nightly builds for them for SLED 11 LSB builds to ensure CMake remains compatible with the LSB.


SUMMARY:
==========
We are currently using CMake and it meets our needs. No system is perfect, but it's the best solution we've looked at so far. It's a little more complicated than would be ideal, but the GUI and ncurses tools do help reduce this, so we have our main devs maintain the project files and other devs use the graphical tools.

Obviously there will be other systems we haven't tried, but our team would suffer "change fatigue" if we made yet another shift, so there would have to be a good reason to do so. Currently, CMake works for us. YMMV.



On 13/05/2011, at 6:21 AM, Thiago Macieira wrote:

> On Thursday, 12 de May de 2011 14:38:37 Ian Monroe wrote:
>> On Thu, May 12, 2011 at 14:15, Doug Schaefer <cdtdoug at gmail.com> wrote:
>>> On Thu, May 12, 2011 at 12:09 PM, Ian Monroe <ian at monroe.nu> wrote:
>>>> So whatever qmake+1 is, it shouldn't let configuration be an
>>>> afterthought. And I hope we just use cmake.
>>> 
>>> +1 for cmake. It's out there, it's customizable, and if needed, we
>>> should be able to get changes upstream. I don't think it's a good
>>> thing people have to learn yet another build tool. I'd rather they
>>> focus on making great apps with Qt.
>> 
>> The fact that cmake is open to changes can't be emphasized too much.
> 
> They are indeed open for changes. We discussed with them a replacement for 
> qmake about a year and a half ago, but it never went anywhere. Still, Kitware 
> was very responsive to most of our concerns, about the needs of the IDE to 
> control the project file, the device deployment and packaging, etc.
> 
> I think there's a blog on Labs that listed what our requirements were.
> 
> However, one thing they were not open for change is the language.
> 
> -- 
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>  Senior Product Manager - Nokia, Qt Development Frameworks
>      PGP/GPG: 0x6EF45358; fingerprint:
>      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
> <signature.asc>_______________________________________________
> Qt5-feedback mailing list
> Qt5-feedback at qt.nokia.com
> http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback

--
Dr Craig Scott
Computational Software Engineering Team Leader, CSIRO (CMIS)
Melbourne, Australia