Hi,<div><br></div><div>As a workaround, I built GDCM with the flag GDCM_USE_VTK set to OFF. Then, I built ITK with the flag ITK_USE_SYSTEM_GDCM enabled and finally, I rebuilt GDCM setting the flag GDCM_USE_VTK to ON.<br><br>
</div><div>Thanks for your interest and I hope a good solution <span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; ">will be found</span>.</div><div><br></div><div>Roger</div><div><br><div class="gmail_quote">
On Sun, Jul 18, 2010 at 7:34 PM, Karthik Krishnan <span dir="ltr">&lt;<a href="mailto:karthik.krishnan@kitware.com">karthik.krishnan@kitware.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi Stephen:<br><br>All I was suggesting was to move the lines :<br><br>  set( METAIO_USE_NAMESPACE .. )<br>  set( METAIO_NAMESPACE .. )<br>  set( METAIO_LibrariesToLinkAgainst .. )<br><br>over to the parent directory, where there is no need to check VTK_VERSION etc, and then recurse into the MetaIO directory. Right now, there are switch statements in the MetaIO CMakeLists.txt files stating &quot;IF METAIO_FOR_ITK&quot; and &quot;IF METAIO_FOR_VTK&quot;. The libraries in the Utilities folder, should not need know that they are being built as a part of ITK or VTK. <br>


<br>Others adopt the same strategy. For instance : <br><br>(a) DICOMParser : The upper level CMakeLists.txt checks if sets the variables : DICOMPARSER_NAMESPACE, DICOMPARSER_LIBRARY, DICOMPARSER_STANDALONE  before recursing in<br>


<br>(b) KWSys. Again, all the options, namespace names etc are set by the toolkit in the parent directory..<br><br>Thanks<br>--<br><font color="#888888">karthik</font><div><div></div><div class="h5"><br><br><br><div class="gmail_quote">
On Sun, Jul 18, 2010 at 5:49 PM, Stephen Aylward <span dir="ltr">&lt;<a href="mailto:stephen.aylward@kitware.com" target="_blank">stephen.aylward@kitware.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex">
<p><br>
It would be nice for code that is duplicated in ITK and VTK (a robot automatically syncs the MetaIO directories in ITK and VTK) to have an automated mechanism for determining if it is being compiled in ITK or VTK.  Any suggestions on what alternate method to use?  I guess we need a var that is specific and not exported via find_package.  I&#39;d rather not create a new one.  Surely one already exists and thereby would be a more general/elegant solution? </p>




<p>So are you saying that having a find_package() in a use.cmake file is ok?</p>
<p>S<br></p>
<p>-- Sent from an Android phone.  Please forgive the typos.</p>
<p></p><blockquote type="cite"><div>On Jul 18, 2010 6:19 AM, &quot;Karthik Krishnan&quot; &lt;<a href="mailto:karthik.krishnan@kitware.com" target="_blank">karthik.krishnan@kitware.com</a>&gt; wrote:<br><br>Alternatively, the fix could also be made in ITK/VTK. After all<br>




VTK-VERSION is used solely to decide if MetaIO is being compiled<br>
within ITK or VTK. One could set the MetaIO-FOR-VTK / ITK from the<br>
parent Utilities directory as well.<br>
</div><p><font color="#500050"></font></p><font color="#500050"><div><br>On 7/18/10, Stephen Aylward &lt;<a href="mailto:stephen.aylward@kitware.com" target="_blank">stephen.aylward@kitware.com</a>&gt; wrote:<br>&gt; Hi,<br>
&gt;<br></div>&gt; I am far from a cmake ex...</font><p></p>

</blockquote>

</blockquote></div><br>
</div></div></blockquote></div><br></div>