[Development] Other buildsystems

[Thiago Macieira]

On Wednesday, 2 de November de 2011 14:42:28 Mathias Hasselmann wrote:
> I constantly see strong opinions against qmake, but actually that thing
> is not that bad as a build system[1]. It permits compact build scripts.
> It is declarative (very important IMHO). It is extensible.

I like qmake when I need to write a simple application that has no 
dependencies outside of Qt, not even the former Qt Mobility. I especially like 
"qmake -project".

But qmake is extremely limited. For any mildly complex project, with optional 
code, configure-time tests, interdependencies, it's a nightmare. When someone 
asks on IRC how to have qmake detect if a dependent library is present, the 
answer I give is "you don't detect libraries with qmake, you declare that you 
need them and let the code fail to compile if those aren't present". It was 
made for Windows developers who don't install third-party packages and use Qt 
only.

And to add insult to injury, despite the valiant efforts by Marius and Ossi, 
the qmake codebase is rotting. And what you say:

> Its worst problem is lack of documentation and therefore a big bunch of
> inconsistent .prf files and a big bunch of lost gems
> in /usr/share/qt4/mkspecs
> 
> Other than that it almost works as advertised.
> 
> So how about updating the documentation and cleaning up the mkspecs
> folder instead? Surely not the most fancy job, but maybe much more
> reasonable than doing things from scratch or even mixing stuff.

> [1] Says someone with strong roots in autotools, but fully accepting it
> doesn't fit into Qt's scope.

I was also one of the few in the KDE world that didn't complain too much about 
autotools. Autoconf' and Automake, coupled with KDE's am_edit or replacing 
automake with unsermake, was quite usable. I still miss config.log from 
autoconf -- trying to debug why something went wrong in CMake usually involves 
adding message() errors to the scripts.

The problem was libtool -- building a project like KDELibs 3.5 on a farm took 
about 45 minutes back then. It was about 20 minutes spent compiling, using the 
build farm, then the next 25 minutes the farm was mostly idle, while your 
machine was at 100%. Of those 25 minutes of CPU time, it must have been 1 or 2 
minutes of linking and 23 of shell scripts.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
     Intel Sweden AB - Registration Number: 556189-6027
     Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20111102/5a5a47b6/attachment.sig>