[CMake] include_directories(...) versus set_directory_properties(PROPERTIES INCLUDE_DIRECTORIES ...)

[David Cole]

I think it's mostly just a speed/space trade-off. If you don't want to 
consume the RAM temporarily (and in this case, I think it's a given, 
that we really don't want to consume 14G of RAM.....) then we'll have 
to spend the time doing the de-duplication on the way in.

Although, the data structures may not be in the right places already, 
they could easily be added.

I can't remember, though: is there a reason why we wouldn't want or be 
able to expand an input to an absolute path at the time it's given 
(current directory issue, or something else?) -- because a prerequisite 
to de-duplicating is referring to the directories in their full path 
canonical fashion.

That's just the quick brain dump version. If necessary, I can actually 
look at old commits, or the current code to try to refresh my memory.


D



-----Original Message-----
From: Brad King <brad.king at kitware.com>
To: Marcel Loose <loose at astron.nl>
Cc: cmake <cmake at cmake.org>; David Cole <dlrdave at aol.com>; Stephen 
Kelly <steveire at gmail.com>
Sent: Mon, Feb 3, 2014 11:51 am
Subject: Re: [CMake] include_directories(...) versus 
set_directory_properties(PROPERTIES INCLUDE_DIRECTORIES ...)


On 01/30/2014 03:08 AM, Marcel Loose wrote:
> cmake was consuming a whopping 14GB(!) of RAM memory.
[snip]
> include_directories() is used inside a macro that is called
> quite a lot in order to resolve cross-dependencies. This never was a
> problem, because CMake automatically performed de-duplication of 
include
> paths; until version 2.8.8.

IIUC it still does de-duplication but delays doing so until the
generation step.  Therefore in this use case the configuration
step buffers the duplicates.

Steve, David, having worked on these changes, what do you think
about teaching include_directories and target_include_directories
to skip appending a path that already exists in each dir/target
property?

-Brad