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
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
