[CMake] Include-Dir order problem

[Andreas Pakulat]

On 16.02.11 07:03:32, David Cole wrote:
> On Wed, Feb 16, 2011 at 2:32 AM, Andreas Pakulat <apaku at 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.

Well, I think for not-that-important features this is true, but being able
to fully control the include-dirs for a given source file (or target) is a
pretty substantial thing for a buildsystem. In addition my understanding (I
did not read all comments on the bugreport) was that adding this wouldn't
break XCode generator, it would simply mean that include-scanning wouldn't
work as well there, so the user may have to run cmake itself manually if
one of the includes in such directories changes.

Anway, apparently I'm not able to convince the people doing the work that
this should be changed, so I'll stick with yet another hack around cmake's
behaviour (until the code can be fully cleaned up).

Andreas

-- 
You will always get the greatest recognition for the job you least like.