Re: Successfully merged projects

[Jordi Gutiérrez Hermoso]

2011/4/11 John W. Eaton <address@hidden>:
> On 11-Apr-2011, Jordi Gutiérrez Hermoso wrote:
>
> | whether to stay with qmake, or use CMake, or autotools itself, but I
> | expect building Qt with autotools will be quite a challenge,
> | considering KDE's decision a while ago to migrate from it to CMake.
>
> Perhaps building Qt itself would be quite a challenge, but we are
> just building an application using Qt, aren't we?  Is that
> significantly different from building other applications using
> libraries and header files written in C or C++?

Yes, because Qt isn't "really" C++, but expands the C++ language with
the meta-object compiler. It's more than just CPP macros; the MOC
emits code used for Qt's signals and slots system.

> Don't we just need to discover whether the necessary libraries and
> header files are needed?

And run the MOC on them. Evidently it can be done with autotools; KDE
was doing it for a long time, but obviously for them, it wasn't the
easiest way.

I also just realised an important limitation of qmake: it can't
reliably do out of source builds, as far as I can tell. It appears
that it can place object code out of the source tree, but the final
binaries can't be easily built elsewhere. This would be rather
uncomfortable for development, since I keep parallel debug and
optimised builds, and I actually encourage other devs to work this
way. You really need both, unless you're smarter than I and can
second-guess gcc's optimisations when you're debugging.

qmake gives me the impression of being a quick Qt hack with little
development since it was initially created. But Michael suggests this
is the wrong impression. I'd be glad to be proven wrong, qmake
certainly is easier to use, but I hope this isn't at the expense of
flexibility with building.

- Jordi G. H.