/usr/local/include in _KDE4_PLATFORM_INCLUDES on FreeBSD?

[Alexander Neundorf]

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? :)

Yes. We should give it a try in FindKDE4Internal.cmake first.

> Is it OK to override/extend variables such as
> CMAKE_{C,CXX}_IMPLICIT_INCLUDE_DIRECTORIES in
> WhateverNotInCMakeItself.cmake?

I wouldn't object in this case.

Alex