[cmake-developers] target_include_directories branch in stage

Brad King brad.king at kitware.com
Mon Nov 7 12:57:40 EST 2011


On 11/6/2011 5:45 PM, Stephen Kelly wrote:
> As discussed on the cmake user mailing list, I'm interesting in implementing
> the feature of target specific and configuration specific include
> directories.

Thanks for working on this.

> I've pushed the target-include-directories branch to stage, which implements
> the feature. I started out as prototyping, but I ended up implementing API
> that I think makes sense. I have not merged it into next yet as it is not
> certain if it should be in the next release. 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.

> David mentioned one issue is whether the include directories of a target
> property should overwrite those of the directory property (added with the
> command include_directories). Like others on the other thread, I would
> expect the final list of includes to be determined by addition. For example:

One problem with determining by addition is the ordering, and a good deal
of your message talks about that.  It is not just dir-vs.-target ordering.
Where do the per-config lists appear?  Let's ignore per-config rules for
the moment and focus on dir-vs.-target, and return to per-config further down.

Unlike link rules we don't have any explicit dependencies or ordering
constraints among include directories.  Ideally all include directories
would contain a disjoint set of files so that the order wouldn't matter,
but that isn't going to happen in general.  Unless we can ask users to
specify ordering constraints we cannot do any automatic ordering.  We
have no good way to merge/combine multiple include directory lists.

The solution has to be based on only a *single* include directory list.
We already do this for link libraries.  The non-target link_directories
and link_libraries commands just append to lists kept for each directory.
When a target is created it's per-target link information is initialized
by copying the current directory-level version.  After that only the
target_link_libraries command can add more rules for a target.

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).

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.

> target_include_directories(foo CONFIG_TYPE DEBUG debug_helper.h)

I'd like to get this working using only the raw target property first:

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

and discuss a new command separately later.

> * I have only tried to implement this with the makefile generator and have
> so far only tested it with "Unix Makefiles". One of the bugs says XCode
> can't do source-level includes. Can it do target-level includes?

I haven't checked recently but I think it can do both.  The concern may be
per-source flags that vary by configuration.

> Would I have to implement this for all generators before it would be
> considered for acceptance?

Yes, at least someone would have to implement it for each generator.

> 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.

-Brad



More information about the cmake-developers mailing list