[ITK Community] Integrating ITK into our own SDK
Michael Jackson
mike.jackson at bluequartz.net
Thu Mar 13 13:09:05 EDT 2014
Thanks for the example. The thing I don't like about "ExternalProject_Add()" is that if you do a "Rebuild" of your project then you are also rebuilding ITK which takes a while.
But even the script that you linked to _assumes_ that one has built ITK but NOT done an actual install. Because when ITK is installed there are no longer any "Debug/Release" directories but just the normal bin, lib, include, share directories.
So even if I build ITK in the final build location, zip up the installation and include that in my SDK installation it will still be wrong because all the *.cmake files will be pointing to some other potentially nonexistent location because the end developer and I need to install ITK in different locations.
In ITK's cmake files is there a macro or function that was written to wrap the add_library() call by chance? That would be convenient to just simply update that one macro/function with a _debug tag for debug libraries.
---
Mike J.
On Mar 13, 2014, at 12:46 PM, Andras Lasso <lasso at queensu.ca> wrote:
> The main advantage of Debug/Release/etc. directories on Windows is that you don't need to reconfigure your project if you switch between different build modes, so don't go back to CMake to change any options. A solution is to leave the install prefix alone and specify a common CMAKE_RUNTIME_OUTPUT_DIRECTORY for all projects. See an example here that works for Win/Linux/Mac for both pre-built and external project ITK:
> https://www.assembla.com/code/plus/subversion/nodes/3228/trunk/PlusBuild/External_ITK.cmake
>
> Andras
>
> -----Original Message-----
> From: Community [mailto:community-bounces at itk.org] On Behalf Of Michael Jackson
> Sent: March 13, 2014 10:36 AM
> To: Matt McCormick
> Cc: community at itk.org
> Subject: Re: [ITK Community] Integrating ITK into our own SDK
>
> So that didn't work. Here is what I tried. On windows (VS2013 Pro) I configured ITK to have an install prefix of C:/Developer/x64/ITK/Debug, configured, built in Debug and installed. I then went back to CMake and reset the install prefix to C:/Developer/x64/ITK/Release, configured, built in Release and installed.
>
> Now I exported the ITK_DIR environment variable as C:/Developer/x64/ITK and tried to configure our own project and it fails to find ITK because CMake can not find the *.cmake files that ITK would normally install but since the ITK_DIR really points to a directory above there it _really_ should point it does not work.
>
> So, back to my original question. how do developers on Windows, specifically Visual Studio, develop against ITK? Do they just configure ITK and build in place and then just point their projects to the ITK Build directory? I am hesitant to try to work with Static Libraries as our project uses plugins and there can be cross-talk among the plugins. So if we have multiple Developers writing multiple plugins where each plugin links agains their own ITK I am foreseeing trouble in the future with that setup (Again on Windows)..
>
> Has anyone else ever made this type of request of ITK in the past?
>
> Thoughts and Suggestions are Welcome?
>
> --
> Mike Jackson
>
>
> On Mar 12, 2014, at 3:27 PM, Matt McCormick <matt.mccormick at kitware.com> wrote:
>
>> Hi Mike,
>>
>>
>> On Wed, Mar 12, 2014 at 1:54 PM, Michael Jackson <mike.jackson at bluequartz.net> wrote:
>> So what you are suggesting is that when I build ITK I would build ITK In Debug and then install to (for example) C:/ITK/Debug and when building in Release install to C:/ITK/Release?
>>
>> Yeap.
>>
>>
>> Would that mess up the actual use of
>> find_package(ITK) in my own project? Would find_package(ITK) actually be able to distinguish between the Debug and Release builds?
>>
>>
>> It would work best with two builds of the project.
>>
>> HTH,
>> Matt
>
> _______________________________________________
> Community mailing list
> Community at itk.org
> http://public.kitware.com/cgi-bin/mailman/listinfo/community
More information about the Community
mailing list