[cmake-developers] target_include_directories branch in stage

Stephen Kelly steveire at gmail.com
Tue Nov 29 07:34:54 EST 2011


Brad King <brad.king at ...> writes:

> 
> On 11/6/2011 5:45 PM, Stephen Kelly wrote:I'd prefer it to be though if
> > we can sort out the issues with what should be the target feature set.
> 
> Good.  We can work on this and revise/rewrite the topic there first and then
> merge to next for testing when the design is more mature.
>

I've been working on this topic again, but I forgot that I had not merged it
into next. I think I properly reverted it though.
  
> The INCLUDE_DIRECTORIES property of a target must be the *only* list
> from which the final include directory list is constructed.  When a target
> is created the current directory-level include directories must be used
> to initialize the list.  Further include_directories() calls in the same
> directory must append not only to the directory-level list but also to
> the property for all existing targets.  At any intermediate point a
> target's property can be modified independently (see the set_property
> command example below).

This works for me locally now.
 
> Now we can return to per-config include directories.  To incorporate them
> into the same single list, we will need some kind of markup on a per-entry
> basis.  This is similar to the "debug/optimized" keywords used by the
> target_link_libraries command, but must be more well designed.  Perhaps
> a syntax similar to generator expressions in custom commands can work.
> I'll have to think more about it.

I worked on the functionality for per-config target includes, but the syntax is
not right yet. For now it's:

  set_property(TARGET foo APPEND PROPERTY INCLUDE_DIRECTORIES ${foo_INCLUDES})
  set_property(TARGET foo APPEND PROPERTY INCLUDE_DIRECTORIES_DEBUG ${bar_INCLUDES})

get_property(VAR foo INCLUDE_DIRECTORIES_DEBUG) # VAR is Always empty

get_property(VAR foo INCLUDE_DIRECTORIES) # In Debug configuration, VAR is
# foo_INCLUDES and bar_INCLUDES. In non-Debug it's foo_INCLUDES only.

> > So before I merge this into next, I'm wondering if this feature can be
> > considered for inclusion in 2.8.7?
> 
> Whatever features are mature and merged to master before the release will
> be in it.  We won't hold up a release for this though.

At the moment, all CMake unit tests pass for me with the branch (and I've just
fixed the style), but I think not all generators are configured to build for me,
so they remain unported for now. Are special switches needed to build CodeBlocks
and Eclipse Generators?

At this point I'd like some guidance on whether the general approach I took is
the correct one, and where I should go from here. I'm not familiar with lots of
parts of CMake that I'm touching, and there are lots of classes whose
responsibility and interactions with the other classes is not clear to me
(GlobalGenerator, LocalGenerator, LocalUnixMakefileGenerator3 etc). cmMakefile
doesn't seem to represent a Makefile. Is the name historical? 

Anyway, while information on those classes might be useful, eyes on the patch
and feedback on the approach would be more so. My approach so far has been to
attempt to remove the use of cmMakefile::GetIncludeDirectories from everywhere
except cmTarget (which uses it to initialize its own directories) and replace it
with calls to the target for the include directories.

Thanks,

Steve.





More information about the cmake-developers mailing list