Re: Successfully merged projects

[Michael Goffioul]

2011/4/11 Jordi Gutiérrez Hermoso <address@hidden>:
> 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?

As I said, as long as you use the Qt-provided class, there is very little
(if any) to discover as everything is already abstracted by Qt.

> 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.

You can read this for some details about why KDE decided to move away
from autotools:
http://dot.kde.org/2007/02/21/road-kde-4-cmake-new-build-system-kde
Besides, I think another reason for the move was portability to other non-GNU
non-GCC platforms.

> 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.

When using MSVC, by default qmake compiles debug and release
code into separate dirs and put the binaries also into separate
dirs, outside of the source directory.

Michael.