On Wed, Feb 16, 2011 at 2:32 AM, Andreas Pakulat <ap...@gmx.de> wrote: 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. >
In my opinion, this is not sad, but commendable. I *hate* the features of CMake that only work with generator a, b and c, but not the rest of them. Features of CMake that only work under *some* circumstances are frustrating to deal with at best. > > 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 >
_______________________________________________ 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