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

Marcel Loose loose at astron.nl
Thu Jan 30 03:08:48 EST 2014


Hi all,

Recently I ran into a problem with a medium-large sized project with
newer CMakes. At first I didn't know what was going on: a cmake run
started to crawl, until it almost came to a standstill and then the OS
killed my login session. It turned out that, just before being logged
out forcibly by the OS, cmake was consuming a whopping 14GB(!) of RAM
memory.

Time for some digging. Luckily I have a number of different version of
CMake lying around on my system, so it was quite easy to figure out that
CMake < 2.8.8 behaved normally, wheras CMake >= 2.8.8 would just blow
up. When I started to print some variables and properties I understood
why: my list of include paths had grown ridiculously large. I won't go
into detail about the setup of this specific project, but suffice it to
say that 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.

Now my question. What is the proper (or best) way to handle this. I've
been thinking along the following line: replace the call to
include_directories() in the offending macro with:

-    include_directories(${_dirs})
+    list(APPEND _inc_dirs ${_dep_inc_dirs})
+    list(REMOVE_DUPLICATES _inc_dirs)
+    set_directory_properties(PROPERTIES INCLUDE_DIRECTORIES "${_inc_dirs}")


Any suggestions or comments?

Best regards,
Marcel Loose.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: loose.vcf
Type: text/x-vcard
Size: 292 bytes
Desc: not available
URL: <http://www.cmake.org/pipermail/cmake/attachments/20140130/806969cb/attachment.vcf>


More information about the CMake mailing list