make KDE4_AUTOMOC compatible to qmake

[Thiago Macieira]

David Faure wrote:
>On Tuesday 26 June 2007, Thiago Macieira wrote:
>> David Faure wrote:
>> >> Only *.moc files should be included.
>> >
>> >You're talking about qmake? I tested with foo.cpp including both
>> > moc_foo.cpp and foo.moc (when both foo.cpp and foo.h have a
>> > Q_OBJECT) and it worked fine.
>>
>> No, I'm talking about us. We shouldn't include other .cpp files.
>
>We need a solution for Q_OBJECT in both foo.h and foo.cpp  ...
>if the only mechanism we have is to create a foo.moc then we can't
>handle that situation (which is however very common, when having public
>API and internal classes; requiring ugly foo_p.h files currently).

Agreed. But allowing .cpp files to be linked isn't the only solution. I 
prefer having foo_p.h headers in all such cases.

Imagine this:
foo.h and foo.cpp both contain Q_OBJECT
foo.cpp contains: #include "foo.moc"
OR foo.cpp contains: #include "moc_foo.cpp"

That moc file will be created for which one of the two? The header or the 
source? Well, it has to be from foo.cpp in BOTH cases. Additionally, in 
BOTH cases, the buildsystem must arrange to moc foo.h and compile it, as 
a C++ source file. Which leads me to say moc_foo.cpp should never be 
included, as it could be used by the buildsystem for the standalone 
header.

Supporting both also makes a much more complex macro. Take my earlier 
algo:
>For each "foo.cpp"
>  if it contains Q_OBJECT:
>    // this case is common in QtTest-based unit tests
>    it must #include "foo.moc"
>    add command: moc -o foo.moc foo.cpp
>
>For each "foo.h"
>  if it contains Q_OBJECT:
>    if "foo.cpp" contains #include "foo.moc":
>      add command: moc -o foo.moc foo.h
>
>    else if "foo.cpp" contains #include "moc_foo.moc":
>      add command: moc -o moc_foo.moc foo.h
>
>    else if it is in the form "foo_p.h" and
>    "foo.cpp" contains #include "foo_p.moc":
>      add command: moc -o foo_p.moc foo_p.h
>
>    else:
>      add command: moc -o moc_foo.cpp foo.h
>      add "moc_foo.cpp" to the to-be-compiled list

Note how "foo.moc" can refer to both the .cpp file and the .h file (which 
isn't possible on qmake). If we allow both the .cpp and the .h to contain 
Q_OBJECT, then the macro must decide which one "foo.moc" will refer to. 
That is, in the first 'if' of the "for each foo.h" loop, it would have to 
discard the foo.moc include if the file also contains a Q_OBJECT.

And if you change your mind later, you must also remember to run cmake 
again (or touch a CMakeLists.txt) so that the link command line is 
recalculated.

>> It's a lot easier to write rules when you can do wildcard matching.
>
>cmake rules? or independent scripts? moc_*.cpp files are in the builddir
> anyway...

Both. Even though I always build with builddir != srcdir, that's not the 
only possible scenario.

For instance, enable-final scenarios: you have to generate an #include for 
all .cpp in your source, except those that are already #included by 
another .cpp. Much easier to remove the "except" part.

>> >But I guess that doesn't prove much, I might have been linking
>> > moc_foo.cpp twice into the binary?
>>
>> If you had, you'd get linker errors.
>
>So you want to deliberately be incompatible with qmake?

Yes. We already are anyways. We allow headers to generate mocs 
as "foo.moc", without the moc_ prefix.

>This makes cases like phonon, kdchart, and kdgantt harder to handle for
>no good reason IMHO.

The good reason is to have cleaner sources: no .cpp including another. And 
the scripts and rules.

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-buildsystem/attachments/20070626/8eebd376/attachment.pgp