<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Jun 18, 2015 at 1:43 AM, Robert Dailey <span dir="ltr"><<a href="mailto:rcdailey.lists@gmail.com" target="_blank">rcdailey.lists@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><div class="h5">On Wed, Jun 17, 2015 at 4:31 PM, Dan Liew <<a href="mailto:dan@su-root.co.uk">dan@su-root.co.uk</a>> wrote:<br>
> On 17 June 2015 at 12:28, Robert Dailey <<a href="mailto:rcdailey.lists@gmail.com">rcdailey.lists@gmail.com</a>> wrote:<br>
>> Is there a way to only take (recursively) the include directiories from<br>
>> a target or set of targets? I know that include directories propagate<br>
>> when passing targets to target_link_libraries(), but I do not want to<br>
>> link the libs; I only want the include directories.<br>
>><br>
>> How can I do this? Thanks.<br></div></div></blockquote><div><br></div><div>I haven't tested this, but it should be possible to drag in the interface properties explicitly with generator expressions. Something like this:<br><br></div><div>add_executable(Depender ...)<br></div><div>target_include_directories(Depender PRIVATE<br>  $<TARGET_PROPERTY:Dependee1,INTERFACE_INCLUDE_DIRECTORIES><br>  $<TARGET_PROPERTY:Dependee2,INTERFACE_INCLUDE_DIRECTORIES><br>)<br><br></div><div>dtto for other INTERFACE_... properties you might need.<br><br></div><div>Petr<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><div class="h5">
><br>
> I presume recursively you mean propagating the required include<br>
> directories between targets rather anything to do recursively handling<br>
> directories.<br>
><br>
> As you mentioned include directories do propagate but this only<br>
> happens under certain conditions (when using PUBLIC or INTERFACE<br>
> scopes).<br>
><br>
> I don't know of a way of doing it without target_link_libraries but if<br>
> it is necessary for you to do this it sounds like you have bigger<br>
> problems relating to the way you have your project header files<br>
> organised.<br>
><br>
> The approach I use for include directories is to have all includes for<br>
> the project rooted in a single include directory in the source tree<br>
> and have all includes relative to that directory. Then if I you<br>
><br>
> ```<br>
> include_directories(${CMAKE_SOURCE_DIR}/include)<br>
> include_directories(${CMAKE_BINARY_DIR}/include) # for generated header files<br>
> ```<br>
><br>
> in the root of the project you never need to set include paths<br>
> anywhere else for sources that are in your project tree. E.g. if there<br>
> is header file in<br>
><br>
> ${CMAKE_SOURCE_DIR}/include/project/moduleA/interface.h<br>
><br>
> then in the sources this is included as<br>
><br>
> #include "project/moduleA/interface.h"<br>
><br>
> (note there are never relative header file includes).<br>
><br>
> This is the approach that the LLVM project uses which is very simple<br>
> and very clean (take a look at the sources). This also works very well<br>
> for installing your header files, the contents of ${CMAKE_SOURCE_DIR}<br>
> just need to be copied into /usr/include .<br>
<br>
</div></div>Thanks, I will go through this and see if it helps.<br>
<br>
The reason I'm asking this question is because of how I handle unit<br>
tests in CMake right now. Instead of just defining an executable<br>
target for the test and then adding a link dependency on the library<br>
containing the class or set of classes to be tested, I am manually<br>
pulling in the CPP and H file into the test target and building them<br>
inline with the test code. This is to support mocking (I can't mock<br>
objects already compiled into a static library). As such, I need the<br>
transitive includes and defines, but I do not want the transitive link<br>
libraries.<br>
<br>
If there is a better structure or overall approach I'm happy to<br>
listen! This has been a nightmare so far.<br>
<div class=""><div class="h5">--<br>
<br>
Powered by <a href="http://www.kitware.com" rel="noreferrer" target="_blank">www.kitware.com</a><br>
<br>
Please keep messages on-topic and check the CMake FAQ at: <a href="http://www.cmake.org/Wiki/CMake_FAQ" rel="noreferrer" target="_blank">http://www.cmake.org/Wiki/CMake_FAQ</a><br>
<br>
Kitware offers various services to support the CMake community. For more information on each offering, please visit:<br>
<br>
CMake Support: <a href="http://cmake.org/cmake/help/support.html" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/support.html</a><br>
CMake Consulting: <a href="http://cmake.org/cmake/help/consulting.html" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/consulting.html</a><br>
CMake Training Courses: <a href="http://cmake.org/cmake/help/training.html" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/training.html</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" rel="noreferrer" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://public.kitware.com/mailman/listinfo/cmake" rel="noreferrer" target="_blank">http://public.kitware.com/mailman/listinfo/cmake</a><br>
</div></div></blockquote></div><br></div></div>