Hi Raphael, I'm going through FindKDE4Internal.cmake currently to prepare it for KDE frameworks.
If came about this patch from you: http://quickgit.kde.org/index.php?p=kdelibs.git&a=commit&h=59066f389a9ae37b0a5e0d66287b326032c2cfae which references the discussion below. Is this still the case with cmake 2.8.7, i.e. do CMAKE_[C|CXX]_IMPLICIT_INCLUDE_DIRECTORIES still not contain all those directories ? Please have a look at this. If they should, we should try to get this into CMake ASAP. Alex On Wednesday 19 May 2010, Raphael Kubo da Costa wrote: > On Wednesday 19 May 2010 17:53:49 Alexander Neundorf wrote: > > On Wednesday 19 May 2010, Raphael Kubo da Costa wrote: > > > On Wednesday 19 May 2010 17:09:43 Alexander Neundorf wrote: > > > > On Tuesday 18 May 2010, Raphael Kubo da Costa wrote: > > > > > On Tuesday 18 May 2010 18:05:37 Alexander Neundorf wrote: > > > > > > On Saturday 15 May 2010, Raphael Kubo da Costa wrote: > > > > > > > On Monday 10 May 2010 19:26:25 Raphael Kubo da Costa wrote: > > > > > > > > On Monday 10 May 2010 19:13:49 Alexander Neundorf wrote: > > > > > > > > > On Tuesday 11 May 2010, Raphael Kubo da Costa wrote: > > > > > > > > > > On Monday 10 May 2010 18:54:31 Alexander Neundorf wrote: > > > > > > > > > > > On Monday 10 May 2010, Raphael Kubo da Costa wrote: > > > > > > > > > > > > Hey there, > > > > > > > > > > > > > > > > > > > > > > > > I was trying to update kdelibs today on FreeBSD and > > > > > > > > > > > > noticed nepomuk kept failing to compile because some > > > > > > > > > > > > methods were not found in Soprano. > > > > > > > > > > > > > > > > > > > > > > > > It turns out kdelibs/nepomuk/query/CMakeLists.txt's > > > > > > > > > > > > include_directories() call put KDE4_KDECORE_INCLUDES > > > > > > > > > > > > before SOPRANO_INCLUDE_DIR, so my system-wide Soprano > > > > > > > > > > > > headers (in /usr/local/include) were being used > > > > > > > > > > > > instead of my trunk Soprano headers in > > > > > > > > > > > > $HOME/kde4/include. > > > > > > > > > > > > > > > > > > > > > > > > Apparently, /usr/local/include was coming from > > > > > > > > > > > > _KDE4_PLATFORM_INCLUDE_DIRS. > > > > > > > > > > > > > > > > > > > > > > This must be X11_INCLUDE_DIR. Can you confirm this ? > > > > > > > > > > > > > > > > > > > > According to what I saw on FindKDE4Internal.cmake > > > > > > > > > > yesterday, yes. And yes, X11 is inside /usr/local. > > > > > > > > > > > > > > > > > > Hmm, we could remove X11_INCLUDE_DIR. One could argue > > > > > > > > > whether this would be a bugfix or a potentially source > > > > > > > > > incompatible change. But even then, couldn't this also > > > > > > > > > happen with any other include dirs used in the "right" > > > > > > > > > order ? > > > > > > > > > > > > > > > > Hmm, you mean if some other dependency was found in > > > > > > > > /usr/local and it ended up being included via > > > > > > > > include_directories() before $MYLOCALKDEPREFIX? Probably... > > > > > > > > > > > > > > > > I'm not sure if there's a proper "fix" for this. Why isn't > > > > > > > > /usr included by CMake? > > > > > > > > > > > > > > Ping? :) > > > > > > > > > > > > Hmm, I think there may be no better solution than to manually > > > > > > take care of a good order for the include directories... > > > > > > I mean, removing X11_INCLUDE_DIR there would fix this one issue, > > > > > > but this can happen for other packages too... > > > > > > > > > > Yep, that's why I was trying to understand why /usr isn't included > > > > > by CMake via include_directories(). Maybe there could be a way for > > > > > it to do the same with /usr/local, so that it's always used with a > > > > > lower priority than the rest? > > > > > > > > I guess this is because /usr/include is part of CMAKE_[C| > > > > CXX]_IMPLICIT_INCLUDE_DIRECTORIES, which is set in > > > > cmake/Modules/Platform/UnixPaths.cmake. > > > > Maybe the compiler/gcc could be queried instead so the list is built > > > > dynamically. This is done now already for the Eclipse generator, see > > > > cmake/Modules/CMakeFindEclipseCDT4.cmake > > > > > > > > What do you think about this ? > > > > > > Looking at CMakeFindEclipseCDT4.cmake, that'd mean querying gcc with > > > -dD, right? That sounds good and reasonable IMO. > > > > At the time when UnixPaths.cmake is loaded, the compiler is not yet know. > > So doing this would have to happen at a later point, maybe in > > Modules/Compiler/GNU.cmake (or in FindKDE4Internal.cmake). > > > > Can you try to come up with a patch ? > > Doing that in Modules/* would mean building CMake from git, posting a patch > to its bugzilla and not running any stable version until it's applied and > a new release is made; doing that in FindKDE4Internal.cmake means I can > simply commit that to trunk after review, right? :) > > Is it OK to override/extend variables such as > CMAKE_{C,CXX}_IMPLICIT_INCLUDE_DIRECTORIES in > WhateverNotInCMakeItself.cmake? _______________________________________________ Kde-buildsystem mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-buildsystem
