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.k...@kitware.com>
To: Marcel Loose <lo...@astron.nl>
Cc: cmake <cmake@cmake.org>; David Cole <dlrd...@aol.com>; Stephen Kelly <steve...@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


--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Reply via email to