<div dir="ltr">I was about to reply, but Ben's response is better than what I'd drafted.  But that won't stop me from adding a couple more points:<div><br></div><div>The module macros are not as well encapsulated as they could be (they require some undocumented cmake variables to be set).  Also, in addition to the fact that all the macros themselves might not be exported yet, I don't know if all the necessary info for built modules is exported, either (especially for "install").</div><div><br></div><div>I hadn't even thought about CMake 3, but the extra properties will definitely be a huge help.</div><div><br></div><div> - David</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 10, 2016 at 1:50 PM, Ben Boeckel <span dir="ltr"><<a href="mailto:ben.boeckel@kitware.com" target="_blank">ben.boeckel@kitware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, Feb 10, 2016 at 15:35:41 -0500, Berk Geveci wrote:<br>
> This would be a great thing to have. Is the issue on the CMake<br>
> infrastructure side?<br>
<br>
</span>Yeah. It's essentially the same problem ParaView has with an external<br>
VTK: VTK doesn't export all of its infrastructure macros properly<br>
(particularly testing and external data) in an install tree. There are<br>
probably other assumptions laying around that other projects trip up on<br>
(e.g., some setting VTK has which another project might want to change<br>
or the fact that VTK is built from within VTK's source tree). I don't<br>
know that an exhaustive (or comprehensive) list of issues exists. It<br>
will be something that will kept in mind when CMake 3 features are used<br>
in the module system.<br>
<span class="HOEnZb"><font color="#888888"><br>
--Ben<br>
</font></span></blockquote></div><br></div>