KDE/kdelibs/cmake/modules

[David Faure]

On Thursday 16 February 2006 19:59, Alexander Neundorf wrote:
> I think we have three options:
> -rename addressbook.cc
Of course. But this won't be the only place where foo/bar.h and blah/bar.h exist,
so better find a solution at the build system level.
This is also why I don't really want to use custom-build-rules solutions either.

On the other hand the current source layout makes little sense (libkab.la is only
used for kab2kabc), so my fix includes moving kab2kabc to the kab subdir,
to compile the program entirely from there.

> I think relying on the order of include dirs would suck.

Hmm, just when I finally got it to work ;-)

First with the KDE4Macros.cmake patch which I committed and then reverted,
to create foo/bar.moc from foo/bar.h (I think this makes sense, no?).
But it means include_directories fixes for several places in kdelibs, due to that.

And finally in kabc the fix is attached. Tell me what you think.

I think 
include_directories( BEFORE ${CMAKE_CURRENT_SOURCE_DIR} ${CMAKE_CURRENT_BINARY_DIR} )
is something that would make sense in every cmakelist (-> macro needed).
When you write #include "foo.h" in a file, you don't expect that a foo.h file in another directory
will be preferred... Automake compiled from that dir (unlike cmake), and had -I. ...

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kabc.diff
Type: text/x-diff
Size: 4190 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-buildsystem/attachments/20060216/b6578483/attachment.bin