[cmake-developers] target_include_directories branch in stage

[David Cole]

On Sunday, January 8, 2012, Stephen Kelly <steveire at gmail.com> wrote:
> On 12/05/2011 03:17 PM, Brad King wrote:
>>
>> On 12/4/2011 12:49 PM, Stephen Kelly wrote:
>>>
>>> I've pushed the branch to my gitorious clone again.
>>>
>>> https://gitorious.org/~steveire/cmake/steveires-cmake
>
> Hi,
>
> I'm revisiting this now that CMake 2.8.7 is out.
>
> I've force pushed my branch:
>
>
https://gitorious.org/~steveire/cmake/steveires-cmake/commits/target-include-directories
>
> For context, the branch as it was on December 4th is preserved here:
>
>
https://gitorious.org/~steveire/cmake/steveires-cmake/commits/target-include-directories-old
>
>>
>> Thanks.  Why do you maintain a special std::vector<std::string> member
>> to hold the INCLUDE_DIRECTORIES target property?
>
> Mostly to simplify the implementation so that I don't need to serialize
and de-serialize in multiple places. I also figured it must be faster to
serialize and deserialize over const char * all the time in the multiple
places that is needed.
>
>
>> I think the property
>> can be stored just like any other property during configuration.  Then
>> the generators can use ExpandListArguments.
>
> Would that mean that every generator would have to ensure that the
includes were unique etc?
>
>> Initialization from the
>> directory property value can just be added to cmTarget::SetMakefile:
>>
>>  this->SetPropertyDefault("INCLUDE_DIRECTORIES", 0);
>>
>
> I tried this (also removing this->IncludeDirectories = makefileIncludes;
from the same function), and it makes the tests fail. This doesn't surprise
me, as as far as I knew and read from the code, SetPropertyDefault is for
initializing a property with the content of the property with the same name
with a "CMAKE_" prefix.
>
> If I've understood what you meant here, please expand.
>
>> The directory-level IncludeDirectories vector can probably also go
>> away in favor of a normal directory property if things are properly
>> refactored.
>>
>>> The top two commits need to be reviewed and have real fixes decided and
>>> written for them. Should the memoization be removed?
>
> I have removed the last two commits from the branch and added a separate
commit to remove the memoization.
>
> Once again, the tests all pass for me. However, I have only tested with
the "Unix Makefile" generator. The other generators (eg for Windows, Mac?)
likely do not work.
>
> How can this feature now be moved forward? Do I need to convince someone
to volunteer to port the other generators? Should I just file a bug for
porting the other generators and wait (possibly making the feature bitrot)?
>
> Thanks,
>
> Steve.
> --
>
> 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
>

I volunteer to make sure this branch works with Xcode and Visual Studio.
I'll get to it within the next week...

Thx,
David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20120108/0d3ce81b/attachment.html>