FILE(REMOVE) and FILE(APPEND) don't resolve relative filenames the same way

Alexander Neundorf neundorf at kde.org
Mon Mar 9 22:12:45 CET 2009


On Friday 06 March 2009, Brad King wrote:
> David Faure wrote:
> > On Friday 06 March 2009, Brad King wrote:
> >> If every Qt project needs something like this, wouldn't it make more
> >> sense for Qt itself to provide an executables with the capabilities of
> >> kde4automoc?
> >
> > Why would Qt do that? They still use and provide QMake (which includes
> > this functionality), they don't have much interest in cmake,
> > unfortunately...
>
> So qmake does it if you specify your build in their format, but provides no
> API to get the information otherwise?  (FYI, I've never done any Qt
> development.)
>
> > On the other hand, cmake provides a FindQt4.cmake and QT_WRAP_CPP,
> > but it looks like a half solution. It only handles one case (separate
> > .moc for a .h), not the other 3 cases:
> > C2 - separate moc file for a .cpp,
> > C3 - #included moc file for a .h, and
> > C4 - #included moc file for a .cpp.
>
> This sounds like another great candidate for an issue tracker feature
> request if there isn't one already.

I wouldn't say so.
automocing in general, while convinient, is kind of ugly.
If you do it with cmake macros, then changes are only detected at cmake time. 
But cmake doesn't necessarily run if you change only a cpp file. That's the 
first issue. Second, it becomes a lot of parsing work, and I think this is a 
bit much work for a cmake script.
I'd really recommend to either do the mocing explicitely using the 
QT_WRAP_CPP() macros etc., or be happy with the limited options of the 
qt4_automoc() macro, or use automoc4:
http://websvn.kde.org/trunk/kdesupport/automoc/
http://techbase.kde.org/Development/Tools/Automoc4

Alex


More information about the Kde-buildsystem mailing list