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. _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake