On Wed, Feb 16, 2011 at 2:32 AM, Andreas Pakulat <span dir="ltr"><<a href="mailto:apaku@gmx.de">apaku@gmx.de</a>></span> wrote:<br><div class="gmail_quote">On 16.02.11 03:48:03, Michael Hertling wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div class="h5">
> On 02/15/2011 07:36 PM, Andreas Pakulat wrote:<br>
> > On 15.02.11 17:54:29, Michael Hertling wrote:<br>
> >> On 02/13/2011 01:27 AM, Andreas Pakulat wrote:<br>
> >>> Hi,<br>
> >>><br>
> >>> I've got a somewhat tricky problem here with include directories. I'm<br>
> >>> building a couple of source files and for some of them I need to add an<br>
> >>> include-directory to the front of the list that cmake passes to the<br>
> >>> compiler. At the same time other source files in that directory need to<br>
> >>> not have that include-dir in front of the list.<br>
> >>><br>
> >>> I can't see a way to do this, except by using COMPILE_FLAGS source file<br>
> >>> properties for each and every file to specify include-dirs and not use<br>
> >>> include_directories at all, as COMPILE_FLAGS always end up behind the<br>
> >>> includes.<br>
> >>><br>
> >>> So, am I missing something here? If not I guess I'll have to find that<br>
> >>> bugreport about making include-dirs a source-file property and vote for<br>
> >>> it so it gets included into 2.8.5...<br>
> >><br>
> >> Currently, AFAIK, it's not possible to set source-file-specific include<br>
> >> directories unless one (mis)uses COMPILE_FLAGS which is accompanied by<br>
> >> the shortcoming you've mentioned. Probably, the really clean solution<br>
> >> ATM would be a reorganisation of the sources, but I doubt if the need<br>
> >> for different include directories is an appropriate criterion for a<br>
> >> project's directory layout.<br>
> ><br>
> > Well, all those sources need to be in the same target, so I can't quite<br>
> > see how moving some of the sources into subdirs wuld help with that.<br>
><br>
> Look at the following CMakeLists.txt files:<br>
><br>
> # CMakeLists.txt:<br>
> CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)<br>
> PROJECT(INCLUDEDIRECTORIES C)<br>
> ADD_SUBDIRECTORY(subdir)<br>
> INCLUDE_DIRECTORIES(abc)<br>
> FILE(WRITE ${CMAKE_BINARY_DIR}/main.c "int main(void){f();return 0;}\n")<br>
> ADD_EXECUTABLE(main main.c)<br>
> TARGET_LINK_LIBRARIES(main sub)<br>
><br>
> # subdir/CMakeLists.txt:<br>
> INCLUDE_DIRECTORIES(xyz)<br>
> FILE(WRITE ${CMAKE_CURRENT_BINARY_DIR}/f.c "void f(void){}\n")<br>
> ADD_LIBRARY(sub STATIC f.c)<br>
><br>
> So, main.c and f.c are compiled with different include directories, but<br>
> the "main" target is effectively composed from the same object files as<br>
> if f.c had been explicitly mentioned among the source files for "main".<br>
> If you commute the ADD_SUBDIRECTORY() and INCLUDE_DIRECTORIES() commands<br>
> in the top-level CMakeLists.txt, the include directories for main.c will<br>
> also hold for f.c while the latter still has its own - additional - ones.<br>
><br>
> Things become worse if the target to be built is a shared library.<br>
<br>
</div></div>Exactly my case.<br>
<div class="im"><br>
> Most probably, you don't want an additional libsub.so, so you would<br>
> need to compile f.c at least with "-fPIC" as COMPILE_FLAGS to get<br>
> further along with a static library. Alternatively, you might use a<br>
> RULE_LAUNCH_LINK property in order to capture the object files from<br>
> the subdirectory and incorporate them in the actual target, see [1].<br>
> However, then you would be restricted to a Makefile generator. IMO,<br>
> none of these appoaches is really convincing why one should aim at an<br>
> INCLUDE_DIRECTORIES source file and target property.<br>
<br>
</div>Unfortunately it seems Brad is unwilling to implement this unless it can<br>
be done 'properly' for all generators. Which is sad, but for now I could<br>
solve this with local special header files which are used by those cpp<br>
files that would otherwise need the extra directory in front.<br></blockquote><div><br></div><div><br></div><div>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.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Andreas<br>
<font color="#888888"><br>
--<br>
Your object is to save the world, while still leading a pleasant life.<br>
</font><div><div></div><div class="h5">_______________________________________________<br>
Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Please keep messages on-topic and check the CMake FAQ at: <a href="http://www.cmake.org/Wiki/CMake_FAQ" target="_blank">http://www.cmake.org/Wiki/CMake_FAQ</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://www.cmake.org/mailman/listinfo/cmake" target="_blank">http://www.cmake.org/mailman/listinfo/cmake</a><br>
</div></div></blockquote></div><br>