View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0008189CMakeCMakepublic2008-11-28 04:212016-06-10 14:30
Reportersvaningelgem 
Assigned ToKitware Robot 
PrioritynormalSeverityfeatureReproducibilityN/A
StatusclosedResolutionmoved 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0008189: set include directories as a source file property
DescriptionI would really like to set include directories per source file. I just worked on converting a Makefile system into a CMake system, and they used per-source file includes. So I was not able to convert it very clean.

I think this change is rather trivial.
TagsNo tags attached.
Attached Files

 Relationships
related to 0001968closedStephen Kelly Per-target or per-source include directories 

  Notes
(0014267)
Mathieu Malaterre (developer)
2008-12-02 11:27

copy/paste from cmake ml:

> It would be ideal, to have a way to propagate and aggregate
> include_directories up the add_subdirectory hierarchy. Can you help me
> to find a way to do this?

You can use global properties as global variables. See the
set_property()/get_property() commands. You can also use the
PARENT_SCOPE option to the set() command. Another option is to use
get_directory_property() in the parent directory to get a definition
from the child directory. See the documentation of these commands.
(0014268)
svaningelgem (reporter)
2008-12-02 11:34

What I did was:
> if(MSVC)
> set(_include_flag " /I ")
> else(MSVC)
> set(_include_flag " -I")
> endif(MSVC)

and than per sourcefile:
set_source_files_properties(<file> PROPERTIES COMPILE_FLAGS "{$_include_flag}<directory>")


This works fine, and has the required result... I just don't like to add that include flag switch in my code as I know some systems, but absolutely not as much as the CMake authors can know.
(0014356)
Brad King (manager)
2008-12-15 17:58

Your work-around will not quite fully work. The dependency scanning will not pick up files included from the per-source path added in COMPILE_FLAGS. Therefore rebuilds might not work as expected.

A per-source include path is not a trivial feature to add. It can work in the Makefile generators, but the dependency scanning will be tricky. I think it can work in the VS IDE. However, Xcode doesn't support it AFAIK.
(0014371)
Brad King (manager)
2008-12-16 11:12

What is an example use case of a per-source include directory? I'm sure there are other work-arounds you can try, perhaps using configured source files.
(0014373)
svaningelgem (reporter)
2008-12-16 13:21

Hi Brad,


What I was trying to convert is a project with for example the following structure:

include/dir1/file.h
include/dir2/file.h
src/dir1_source.c
src/dir2_source.c


Now dir1_source.c has include/dir1 as the include directory, and dir2_source.c has the include/dir2 as include directory.
If I include both for both files it'll go wrong very badly.

I know this is a very bad setup, but blame the authors of that project ;-).


XCode is gcc in the backend right? Why wouldn't it be possible to add an include per source file?


Grtz,
Steven
(0014374)
Brad King (manager)
2008-12-16 13:29

The Xcode IDE (and therefore its project file format) records a set of build attributes and then maps these into invocations of the compiler with all the corresponding flags. The IDE does not support special attribute settings on a per-source basis.

In your example, why can't you just put the top-level include directory in the include path and then write

/* dir1_source.c */
#include <dir1/file.h>

/* dir2_source.c */
#include <dir2/file.h>

?
(0014401)
svaningelgem (reporter)
2008-12-18 10:54

I tried to make this work, but it doesn't...

The issue is that the files in dir1 and dir2 are copies from external libraries. When they are updated, the new include files are just copied in there without modifications. Now imagine this:

dir1/a.h --> #include <b.h>
dir1/b.h

if I work via:
/* a.c */
#include <dir1/a.h>

This will include a.h, but it won't find b.h... Unless I set the include directory correct.

I know it's difficult, but I'm just trying to convert them into using CMake ;)
(0014402)
Brad King (manager)
2008-12-18 11:25

If the file 'a.h' wants to include another header from its own directory it should use double-quote include syntax ("b.h") or know its header directory (dir1/b.h), like Boost does (boost/config.hpp). However since it's an external project I guess you're stuck.

If you've copied it one-time into your own source tree I suggest just hacking the headers and adding a README describing why and how to update it when a new one is imported. CMake's source tree does this for a few projects. If you're copying it at CMake time you could try to do some kind of string processing to replace the include lines, but knowing which lines to replace may be tricky.

CMake should really just support this use case at least on the native platforms where it works (not Xcode). I do actually have per-source options partially implemented. Unfortunately it is a rather large change due to some internal issues and I won't be able to get back to it for a while. Your COMPILE_FLAGS workaround is good enough for now.
(0023716)
Greg Sharp (reporter)
2010-12-03 19:36

I find myself needing this feature too.

The use case: my application requires two different 3rd party libraries. Some files require one library, some files require the other, but no files require both. Including the directories from one library breaks the custom build command supplied by the second library, so it would be ideal to set the include directory properties to either a source file or a library target.

Is there any other workaround, or I should use COMPILE_FLAGS as svaningelgem recommends?
(0025440)
Andreas Pakulat (reporter)
2011-02-15 13:33

My use-case for this is easily supporting Qt3 and Qt4 at the same time. In Qt4 some classes from Qt3 are still existing in a Q3XXX way with a q3xxx.h header. At the same time there's a new class QXXX and header qxxx.h for the Qt4 version of the class.

We have code that needs to use the Q3XXX version if compiled against Qt4 but also needs to compile against Qt3. So we have a qt4compat directory prepended to the include-options of the sources that has a qxxx.h which defines Q3XXX to QXXX. This way the code can simply go on using QXXX and work with the Qt3-Compat version when building against Qt4. Its a hack, but it works.

Unfortunately the same target also has files that need to use the new Qt4 version of the class, so for those having the qt4compat directory in the include path is wrong.

The only way out (besides modifying the code) is to be able to set include-directories on a per-source basis.
(0025443)
Brad King (manager)
2011-02-15 13:43

As I explain in 0008189:0014374 it is absolutely *impossible* to implement this feature everywhere unless Xcode gets native support for it.
(0025445)
Andreas Pakulat (reporter)
2011-02-15 17:53

I don't quite get why XCode is being used as excuse for not implementing it. There are other things that are only supported with some generators and not with others already (like building debug+release with one builddir).

Another use case is building java and C++ sources in the same subdir, this also does not work currently as the java-compiler uses include-dirs to name .jar files that should be used. So one has to craft arbitrary subdirectories for such stuff.
(0025446)
Andreas Pakulat (reporter)
2011-02-15 18:49

Sorry if the tone in that last comment sounds rude or harsh, that wasn't my intention.
(0025447)
Brad King (manager)
2011-02-16 08:50

Re 0008189:0025445: It's not an excuse. I'm pointing out that even if the feature were implemented it would not work everywhere.

We simply don't have time to work on this feature at the moment.
(0041474)
Kitware Robot (administrator)
2016-06-10 14:27

Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.

 Issue History
Date Modified Username Field Change
2008-11-28 04:21 svaningelgem New Issue
2008-12-02 11:27 Mathieu Malaterre Note Added: 0014267
2008-12-02 11:34 svaningelgem Note Added: 0014268
2008-12-15 10:46 Bill Hoffman Status new => assigned
2008-12-15 10:46 Bill Hoffman Assigned To => Brad King
2008-12-15 17:58 Brad King Note Added: 0014356
2008-12-16 11:12 Brad King Note Added: 0014371
2008-12-16 13:21 svaningelgem Note Added: 0014373
2008-12-16 13:29 Brad King Note Added: 0014374
2008-12-18 10:54 svaningelgem Note Added: 0014401
2008-12-18 11:25 Brad King Note Added: 0014402
2010-12-03 19:36 Greg Sharp Note Added: 0023716
2011-02-15 13:33 Andreas Pakulat Note Added: 0025440
2011-02-15 13:39 Brad King Relationship added related to 0001968
2011-02-15 13:43 Brad King Note Added: 0025443
2011-02-15 13:43 Brad King Assigned To Brad King =>
2011-02-15 13:43 Brad King Status assigned => backlog
2011-02-15 17:53 Andreas Pakulat Note Added: 0025445
2011-02-15 18:49 Andreas Pakulat Note Added: 0025446
2011-02-16 08:50 Brad King Note Added: 0025447
2016-06-10 14:27 Kitware Robot Note Added: 0041474
2016-06-10 14:27 Kitware Robot Status backlog => resolved
2016-06-10 14:27 Kitware Robot Resolution open => moved
2016-06-10 14:27 Kitware Robot Assigned To => Kitware Robot
2016-06-10 14:30 Kitware Robot Status resolved => closed


Copyright © 2000 - 2018 MantisBT Team