[CMake] Include-Dir order problem

[Andreas Pakulat]

On 16.02.11 03:48:03, Michael Hertling wrote:
> On 02/15/2011 07:36 PM, Andreas Pakulat wrote:
> > On 15.02.11 17:54:29, Michael Hertling wrote:
> >> On 02/13/2011 01:27 AM, Andreas Pakulat wrote:
> >>> Hi,
> >>>
> >>> I've got a somewhat tricky problem here with include directories. I'm
> >>> building a couple of source files and for some of them I need to add an
> >>> include-directory to the front of the list that cmake passes to the
> >>> compiler. At the same time other source files in that directory need to
> >>> not have that include-dir in front of the list.
> >>>
> >>> I can't see a way to do this, except by using COMPILE_FLAGS source file
> >>> properties for each and every file to specify include-dirs and not use
> >>> include_directories at all, as COMPILE_FLAGS always end up behind the
> >>> includes.
> >>>
> >>> So, am I missing something here? If not I guess I'll have to find that
> >>> bugreport about making include-dirs a source-file property and vote for
> >>> it so it gets included into 2.8.5...
> >>
> >> Currently, AFAIK, it's not possible to set source-file-specific include
> >> directories unless one (mis)uses COMPILE_FLAGS which is accompanied by
> >> the shortcoming you've mentioned. Probably, the really clean solution
> >> ATM would be a reorganisation of the sources, but I doubt if the need
> >> for different include directories is an appropriate criterion for a
> >> project's directory layout.
> > 
> > Well, all those sources need to be in the same target, so I can't quite
> > see how moving some of the sources into subdirs wuld help with that.
> 
> Look at the following CMakeLists.txt files:
> 
> # CMakeLists.txt:
> CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
> PROJECT(INCLUDEDIRECTORIES C)
> ADD_SUBDIRECTORY(subdir)
> INCLUDE_DIRECTORIES(abc)
> FILE(WRITE ${CMAKE_BINARY_DIR}/main.c "int main(void){f();return 0;}\n")
> ADD_EXECUTABLE(main main.c)
> TARGET_LINK_LIBRARIES(main sub)
> 
> # subdir/CMakeLists.txt:
> INCLUDE_DIRECTORIES(xyz)
> FILE(WRITE ${CMAKE_CURRENT_BINARY_DIR}/f.c "void f(void){}\n")
> ADD_LIBRARY(sub STATIC f.c)
> 
> So, main.c and f.c are compiled with different include directories, but
> the "main" target is effectively composed from the same object files as
> if f.c had been explicitly mentioned among the source files for "main".
> If you commute the ADD_SUBDIRECTORY() and INCLUDE_DIRECTORIES() commands
> in the top-level CMakeLists.txt, the include directories for main.c will
> also hold for f.c while the latter still has its own - additional - ones.
> 
> Things become worse if the target to be built is a shared library.

Exactly my case.

> Most probably, you don't want an additional libsub.so, so you would
> need to compile f.c at least with "-fPIC" as COMPILE_FLAGS to get
> further along with a static library. Alternatively, you might use a
> RULE_LAUNCH_LINK property in order to capture the object files from
> the subdirectory and incorporate them in the actual target, see [1].
> However, then you would be restricted to a Makefile generator. IMO,
> none of these appoaches is really convincing why one should aim at an
> INCLUDE_DIRECTORIES source file and target property.

Unfortunately it seems Brad is unwilling to implement this unless it can
be done 'properly' for all generators. Which is sad, but for now I could
solve this with local special header files which are used by those cpp
files that would otherwise need the extra directory in front.

Andreas

-- 
Your object is to save the world, while still leading a pleasant life.