Alexander Neundorf wrote: >> You said that you can't detect this case, but why do you have to? Isn't >> there already a check for the Q_OBJECT macro in the cpp file? Wouldn't >> the logic be 'if the <basename>.moc file is included but there is no >> Q_OBJECT in the header, then moc the <basename>.h and put the result in >> <basename>.moc', or does that conflict with another rule? > > I'll put some more work in it over the weekend. > Probably something like this should work. > Or "if it's not my own .moc-file, never assume it's the .moc-file from > another cpp-file (end of story here with Qt5), but try whether it could be > the moc- file from a header". >
Please make the behaviour difference not determined by Qt4 vs Qt5 but by a variable. That is, please make: find_package(Qt4) set(CMAKE_AUTOMOC ON) set(CMAKE_AUTOMOC_STRICT ON) behave with what you call the 'Qt5' behaviour, and find_package(QtCore 5) set(CMAKE_AUTOMOC ON) set(CMAKE_AUTOMOC_STRICT OFF) behave with what you call the 'Qt4' behaviour. That is, introduce a CMAKE_AUTOMOC_STRICT variable to control which mode the automoc stuff works with, and have a different default between Qt4 and Qt5, but allow overriding that default. Porting to Qt5 (for KDE at least) needs to eb a multi-step process for applications depending on kdelibs (and this feature). I think it needs to be possible to run automoc in non-strict mode with Qt5. Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
