/usr/local/include in _KDE4_PLATFORM_INCLUDES on FreeBSD?

[Alexander Neundorf]

On Friday 04 June 2010, Raphael Kubo da Costa wrote:
> On Wednesday 19 May 2010 18:16:36 Alexander Neundorf wrote:
> > 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
>
> Alright, here's a first draft of the patch (also attached). The macro was
> copied from CMakeFindEclipseCDT4.cmake with some parts cut out.
>
> It is called only when the compiler is gcc because I don't know if it would
> work with other compilers (CMakeFindEclipseCDT4.cmake also calls it when
> the compiler being used is Intel's, but I don't even know if we support
> it).
>
> I have also completely overriden the default values, that is, set(foo
> ${bar}) instead of set(foo ${foo} ${bar}) because I believe the initial
> directories (such as /usr/include) will still be present in this call, but
> I may be wrong.
>
> Cheers,
> Raphael
>
> Index: FindKDE4Internal.cmake
> ===================================================================
> --- FindKDE4Internal.cmake      (revision 1133835)
> +++ FindKDE4Internal.cmake      (working copy)
> @@ -1136,8 +1136,34 @@
>     kde_check_flag_exists("/NODEFAULTLIB:libcmtd /DEFAULTLIB:msvcrtd"
> CMAKE_EXE_LINKER_FLAGS_DEBUG "debug")
>  endif(MSVC)
>
> +# This macro is for internal use only
> +# Return the directories present in gcc's include path.
> +macro(_DETERMINE_GCC_SYSTEM_INCLUDE_DIRS _lang _result)
> +  set(${_result})
> +  set(_gccOutput)
> +  file(WRITE "${CMAKE_BINARY_DIR}/CMakeFiles/dummy" "\n" )
> +  execute_process(COMMAND ${CMAKE_C_COMPILER} -v -E -x ${_lang} -dD dummy
> +                  WORKING_DIRECTORY ${CMAKE_BINARY_DIR}/CMakeFiles
> +                  ERROR_VARIABLE _gccOutput
> +                  OUTPUT_VARIABLE _gccStdout )
> +  file(REMOVE "${CMAKE_BINARY_DIR}/CMakeFiles/dummy")
> +
> +  if( "${_gccOutput}" MATCHES "> search starts here[^\n]+\n *(.+) *\n *End
> of (search) list" )
> +    SET(${_result} ${CMAKE_MATCH_1})
> +    STRING(REPLACE "\n" " " ${_result} "${${_result}}")
> +    SEPARATE_ARGUMENTS(${_result})
> +  ENDIF( "${_gccOutput}" MATCHES "> search starts here[^\n]+\n *(.+) *\n
> *End of (search) list" )
> +ENDMACRO(_DETERMINE_GCC_SYSTEM_INCLUDE_DIRS _lang)
> +
> +if (CMAKE_COMPILER_IS_GNUCC)
> +   _DETERMINE_GCC_SYSTEM_INCLUDE_DIRS(c _dirs)
> +   set(CMAKE_C_IMPLICIT_INCLUDE_DIRECTORIES ${_dirs})

I think I would prefer an append here, e.g.
set(CMAKE_C_IMPLICIT_INCLUDE_DIRECTORIES 
    ${CMAKE_C_IMPLICIT_INCLUDE_DIRECTORIES} ${_dirs})
Same for the cxx compiler.


Beside that, I'd say give it a try.

Alex