[cmake-developers] target_include_directories branch in stage

Brad King brad.king at kitware.com
Fri Dec 2 08:55:34 EST 2011


On 12/2/2011 8:35 AM, David Cole wrote:
>> Do you mean I should remove the UI feature of setting the
>> INCLUDE_DIRECTORIES_DEBUG property adding to the include directories of the
>> debug config, or do you additionally mean that I should remove the current
>> implementation that keeps order and keeps the specified config.
>>
>> The current implementation (std::vector<std::pair<std::string, std::string>
>>> ) would work for the UI syntax you suggest below. It seems like removing
>> the implementation detail only for it to be re-added later when the UI
>> syntax is decided would be inefficient.
>>
>> I'm fine with removing the INCLUDE_DIRECTORIES_<config>  UI feature.

Remove both.  The interface will not be of that form.  The implementation
of the future interface I propose will only need a regular string-valued
property that happens to be a semicolon-separated list.  The generators will
take that list and evaluate the $<> syntax in each entry to see if it needs
any per-config filtering.

>>>    $<CONFIG?Debug:/dir/for/Debug>
>>
>> Ok. Is this something that should aim for post-2.8.7? Should I aim to get
>> taget specific INCLUDE_DIRECTORIES into 2.8.7 (within this week) and aim for
>> adding this config-specific feature later (would that be source
>> compatible?).
>
> I, for one, would really like to see per-target include directories in
> 2.8.7, even without per-config support to start with. Then, add the
> per-config support / new generator expressions in a later release.

Yes.  There will be no compatibility problem because the $<> syntax makes
no sense to have as a literal include directory.

-Brad



More information about the cmake-developers mailing list