|
Notes |
|
|
(0014267)
|
|
Mathieu Malaterre
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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. |
|