<div dir="ltr">I should probably clarify the situation (I'm not sure I provided enough info up front). The larger dependencies like ITK are pre-built (I guess one would assume this; we don't rebuild ITK or VTK with every build of our project). So I thought it would be a simple problem of overwrite and then restoring the ITK_DIR value at the right time (e.g. at the point of find_package(ITK ...) for the modules in question). I feel like we've almost got this working. There are some lingering issues that we're still solving, but the respective modules seem to reference the correct versions of ITK now. I guess I'm wondering whether this approach is doomed to fail for a reason we haven't anticipated.<div>
<br></div><div style>I'm doing the replacement as follows:</div><div style><br></div><div style><div># This module uses an older version of ITK (3.2) than the rest of</div><div># the project (4.31), so here we overwrite the ITK_DIR variable</div>
<div># so that the correct version is found.</div><div>MESSAGE( STATUS "ITK_DIR_SECONDARY value: " ${ITK_DIR_SECONDARY})</div><div><br></div><div>MESSAGE( STATUS "ITK_DIR value (before overwrite): " ${ITK_DIR})</div>
<div># Store the primary ITK directory in a temporary variable</div><div>set(ITK_DIR_PRIMARY ${ITK_DIR})</div><div># Overwrite the ITK_DIR cache variable</div><div>set(ITK_DIR ${ITK_DIR_SECONDARY} CACHE STRING "The directory containing a CMake configuration file for ITK" FORCE)</div>
<div>MESSAGE( STATUS "ITK_DIR value (after overwrite): " ${ITK_DIR})</div><div><br></div><div>FIND_PACKAGE(ITK 3.2)</div><div>IF(ITK_FOUND)</div><div><span class="" style="white-space:pre"> </span>INCLUDE(${ITK_USE_FILE})</div>
<div>ELSE(ITK_FOUND)</div><div><span class="" style="white-space:pre"> </span>MESSAGE(FATAL_ERROR "ITK not found. Please set ITK_DIR.")</div><div>ENDIF(ITK_FOUND)</div><div><br></div><div># Restore the original (primary) ITK_DIR value</div>
<div>SET(ITK_DIR ${ITK_DIR_PRIMARY} CACHE STRING "The directory containing a CMake configuration file for ITK" FORCE)</div><div>MESSAGE( STATUS "ITK_DIR value (after restore): " ${ITK_DIR})</div><div>
<br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, May 28, 2013 at 11:30 AM, 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"><div dir="ltr">I just re-read your question. Superbuild won't help.<br><br></div><div class="HOEnZb"><div class="h5">
<div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, May 28, 2013 at 11:29 AM, 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"><div dir="ltr">You could use cmake's superbuild facility to build both itk3 and itk4 in a superbuild tree.<br> <br>
</div><div class="gmail_extra"><div><div><br><br><div class="gmail_quote">On Tue, May 28, 2013 at 11:02 AM, John Drescher <span dir="ltr"><<a href="mailto:drescherjm@gmail.com" target="_blank">drescherjm@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On Tue, May 28, 2013 at 10:16 AM, Zamir Khan <<a href="mailto:zamir.khan@gmail.com" target="_blank">zamir.khan@gmail.com</a>> wrote:<br>
> We have a project where multiple modules rely on ITK. Most modules have been<br>
> upgraded to ITK 4.31, but one still relies on ITK 3.20 and it would take a<br>
> significant effort to upgrade it. In the meantime, is there a way for us to<br>
> keep these modules under a single top-level CMake and have them use their<br>
> respective versions of ITK?<br>
><br>
> We thought we could just try to overwrite the ITK_DIR variable in the<br>
> appropriate place, but our first naive implementation of this did not work.<br>
><br>
> Just wondering if someone has done this and whether it is possible (before<br>
> we dive deeper).<br>
><br>
<br>
</div>On windows I have several completely separate build trees with their<br>
own environment. This way I can build for different compiler versions,<br>
32/64 bit and different versions of libraries like this. Inside the<br>
root of each build tree there is a link to the appropriate Visual<br>
Studio command prompt that has its default folder set to the build<br>
tree root. Also in the root there is a batch file that sets quite a<br>
few _DIR environment variables to help cmake find the correct compiled<br>
libraries. This has worked well for the 5 or so years that I have done<br>
it this way. I do not use INSTALL targets so none of the binaries end<br>
up in Program Files.<br>
<span><font color="#888888"><br>
John<br>
</font></span><div><div>--<br>
<br>
Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Please keep messages on-topic and check the CMake FAQ at: <a href="http://www.cmake.org/Wiki/CMake_FAQ" target="_blank">http://www.cmake.org/Wiki/CMake_FAQ</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://www.cmake.org/mailman/listinfo/cmake" target="_blank">http://www.cmake.org/mailman/listinfo/cmake</a><br>
</div></div></blockquote></div><br><br clear="all"><br></div></div><span><font color="#888888">-- <br>Unpaid intern in BillsBasement at noware dot com<br>
</font></span></div>
</blockquote></div><br><br clear="all"><br>-- <br>Unpaid intern in BillsBasement at noware dot com<br>
</div>
</div></div></blockquote></div><br></div>