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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem