<div dir="ltr">Apologies, the last few messages in this thread had deviated away from remote modules into entirely different territory...</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 10, 2016 at 2:15 PM, Bill Lorensen <span dir="ltr"><<a href="mailto:bill.lorensen@gmail.com" target="_blank">bill.lorensen@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The remote facility is very simple. Provide a foo.remote.cmake file<br>
and in your module create a module.cmake  to specify your vtk<br>
dependencies. The docs assume you want to make a conventional vtk<br>
module,. But, your module can do anything it wants.<br>
<br>
For example in ITK, there are the Sphinx and ITK Wiki Examples. These<br>
both have non-standard directory structures.<br>
<br>
I am currently working on a remote module for the vtk wiki examples.<br>
These will be buildable as a remote module or stand-alone. It is not<br>
that difficult.<br>
<br>
Stay tuned...<br>
<br>
Bill<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
On Wed, Feb 10, 2016 at 4:00 PM, David Gobbi <<a href="mailto:david.gobbi@gmail.com">david.gobbi@gmail.com</a>> wrote:<br>
> I was about to reply, but Ben's response is better than what I'd drafted.<br>
> But that won't stop me from adding a couple more points:<br>
><br>
> The module macros are not as well encapsulated as they could be (they<br>
> require some undocumented cmake variables to be set).  Also, in addition to<br>
> the fact that all the macros themselves might not be exported yet, I don't<br>
> know if all the necessary info for built modules is exported, either<br>
> (especially for "install").<br>
><br>
> I hadn't even thought about CMake 3, but the extra properties will<br>
> definitely be a huge help.<br>
><br>
>  - David<br>
><br>
><br>
> On Wed, Feb 10, 2016 at 1:50 PM, Ben Boeckel <<a href="mailto:ben.boeckel@kitware.com">ben.boeckel@kitware.com</a>><br>
> wrote:<br>
>><br>
>> 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>
>> 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>
>><br>
>> --Ben<br>
><br>
><br>
><br>
</div></div><div class="HOEnZb"><div class="h5">> _______________________________________________<br>
> Powered by <a href="http://www.kitware.com" rel="noreferrer" target="_blank">www.kitware.com</a><br>
><br>
> Visit other Kitware open-source projects at<br>
> <a href="http://www.kitware.com/opensource/opensource.html" rel="noreferrer" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
><br>
> Search the list archives at: <a href="http://markmail.org/search/?q=vtk-developers" rel="noreferrer" target="_blank">http://markmail.org/search/?q=vtk-developers</a><br>
><br>
> Follow this link to subscribe/unsubscribe:<br>
> <a href="http://public.kitware.com/mailman/listinfo/vtk-developers" rel="noreferrer" target="_blank">http://public.kitware.com/mailman/listinfo/vtk-developers</a><br>
><br>
><br>
<br>
<br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
Unpaid intern in BillsBasement at noware dot com<br>
</font></span></blockquote></div><br></div>