[cmake-developers] target_include_directories branch in stage

[Brad King]

On 11/29/2011 7:34 AM, Stephen Kelly wrote:
> 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.

I added another commit to the revert-... branch to fully revert it.
To avoid accidental merges of work-in-progress topics, please instead
create a github.com account, visit

   https://github.com/Kitware/CMake

and use the "Fork" button to get your own repo in which to publish topics.
Then post a link to the topics there for us to fetch and review.  That way
you can rewrite the topic arbitrarily during development.

>> The INCLUDE_DIRECTORIES property of a target must be the *only* list
>> from which the final include directory list is constructed.
>
> This works for me locally now.

Great.  In order to simplify review please publish a revised version using
the above method based on the comments below.  Use "rebase -i" to rewrite
the topic as a minimal set of commits making logical steps.

> I worked on the functionality for per-config target includes, but the syntax is
> not right yet.

Please remove per-config support for now.

With the approach I have in mind it will be a simple matter to add support
for it after the main feature works.  I want to make the approach something
general so it can be applied to other things like link directories.  The
idea is to process the single list in the generator and look for special
syntax that indicates whether each entry is meant for the current config.

I haven't settled on a syntax yet but it will be similar to generator
expressions from add_test and add_custom_command:

  $<CONFIG?Debug:/dir/for/Debug>

This entry would be ignored if the CONFIG? condition doesn't match.  The
cmGeneratorExpression class can be used to evaluate it.

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

Alex?

 > cmMakefile doesn't seem to represent a Makefile. Is the name historical?

Yes.  It really corresponds to a CMakeLists.txt file representing a directory
during the configure step.  Then a cmLocalGenerator subclass represents the
directory during generation.  One instance of a cmGlobalGenerator subclass
corresponds to the entire build.

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

That is correct.

Thanks,
-Brad