[Insight-users] Using ITK with visual studio and not cmake

Michael Jackson mike.jackson at bluequartz.net
Mon Oct 19 13:43:50 EDT 2009 

CMake may be enumerating all those include directories, but your  
project will most likely need every single one of them. Same thing for  
the libraries. My guess is that you will spend about an hour tracking  
down what you need and then you will have your VS Solution the way you  
want it. Which isn't that bad.

   Far as the "just working", John Dresher helped me last week get ITK  
and VS working better together with regards to Debug and Release  
libraries. Just so we are clear, if I do a "rebuild" in my project ITK  
is NOT touched at all. This seemed like a point of confusion in your  
email.

   The way I have things setup is as follows: (Windows 7 currently).

I have ITK located in C:/Users/mjackson/Workspace/ITK-3.14.0. Inside  
that directory I have 2 build directories: i386 and x64. I use cmake  
to configure new VS solutions for each one. Then I have built ITK in  
both debug and release modes. So for those playing along at home, that  
is 4 builds. I now have ITK_DIR set to C:/Users/mjackson/Workspace/ 
ITK-3.14.0/x64 for my 64 bit builds and C:/Users/mjackson/Workspace/ 
ITK-3.14.0/i386 for my 32 bit builds of my own projects.

  Now when I toggle between "Debug" and "Release" in my own VS  
projects, VS is nice enough to pick up the "correct" set of libraries  
from ITK (release or debug). Again, selecting "rebuild" in my VS  
solution does NOTHING to the ITK libraries already built. Only my own  
project is rebuilt.

Hope that helps.
_________________________________________________________
Mike Jackson                  mike.jackson at bluequartz.net
BlueQuartz Software                    www.bluequartz.net
Principal Software Engineer                  Dayton, Ohio

On Oct 19, 2009, at 1:28 PM, Mark Roden wrote:

> OK, I'll just make myself a header that has all those include
> directories in it instead.
>
> Basically, it seems that CMake is just enumerating all directories and
> putting that enumeration into the build list.
>
> See, I don't want to use that Visual Studio project, because it's
> cluttered with all the libraries and so forth.  I don't want to
> rebuild the libraries all the time, I just want them to exist and not
> be touched.  I want to remove them as much as possible as a time sink
> for a 'rebuild all' command, and I want to assume that they will Just
> Work and so not be a potential source of problems.  Of course, that
> last is probably a pipe dream, but at least it's open sourced so I can
> step in if I need to.  I'd also want to have all those warnings on in
> my project, because they've all caused me problems in the past.  I
> also want to be able to lock down to a particular version of the
> library, and then only upgrade as necessary.
>
> So, I have my reasons.  If that means that I have a more complicated
> project file, so be it.
>
> Thanks for the help,
> Mark
>
> On Mon, Oct 19, 2009 at 10:17 AM, Michael Jackson
> <mike.jackson at bluequartz.net> wrote:
>> Answers In line..
>>
>>
>> On Oct 19, 2009, at 12:56 PM, Mark Roden wrote:
>>
>>> On Mon, Oct 19, 2009 at 9:35 AM, John Drescher  
>>> <drescherjm at gmail.com>
>>> wrote:
>>>>>
>>>>> I want to incorporate more libraries than just itk in my  
>>>>> project, and
>>>>> am having a pretty hard time of it.
>>>>>
>>>> I can tell you as a 12 year windows programmer before ever using
>>>> CMake, its much much easier to do this with cmake. And also cmake
>>>> actually a lot of benefit to visual studio. Out of source builds,
>>>> built in unit testing, built in install generator, ability to  
>>>> have one
>>>> project file for all versions of visual studio VC6+... Eventually I
>>>> will convert all my old projects to use cmake and drop  
>>>> the .vsproj and
>>>> .dsp files out of my cvs repository...
>>>
>>> I have a similar level of experience here, and I'm just not that  
>>> into
>>> cmake.  I've learned quite a few tricks with sln files and the like,
>>> and figuring out yet another set of build rules and yet another  
>>> set of
>>> unit testing paradigms and a different source control system (I use
>>> either git or perforce, cvs just gives me hives) is a real  
>>> distraction
>>> from getting work done.
>>
>>  You don't need CVS for ITK. Get the regular released version from  
>> the web
>> site.
>>>
>>> Let me put it this way: the CMake paradigm adopted by itk, that of
>>> single files to accomplish a simple task, is fine for little command
>>> line applications, but not how I want to build an application.  If I
>>> wanted to incorporate other libraries (ie, QT for useful interfaces,
>>> etc), trying to mesh these libraries with those will be most likely
>>> excruciating.  That's why I'm looking for a simple build location,
>>> with dlls, libs, and headers, not to incorporate with an entire  
>>> coding
>>> paradigm.
>>>
>> Actually incorporating other libraries with CMake and ITK is quite  
>> "easy"
>> with CMake... but I'll leave that for another time..
>>
>>> Maybe I don't understand CMake.  Frankly, I really don't want to.  I
>>> just want to use the libraries as libraries, not as a coding style  
>>> or
>>> as a way to organize files.
>>
>> See below..
>>
>>>
>>>>
>>>>>
>>>>> I've built the libraries using the cmake options to build only
>>>>> libraries.
>>>>>
>>>>> I then have a basic hello-world executable that links to the built
>>>>> libraries and includes the itk/code/common directory.
>>>>>
>>>>> I then #include "itkImage.h" at the top of my main file, and  
>>>>> have the
>>>>> body of the main function matching the example from  
>>>>> HelloWorld.cxx in
>>>>> examples/installation
>>>>>
>>>>> When I try to build, I get this error:
>>>>>
>>>>> 1>c:\users\mark\src\itktests\itktestproject\itk
>>>>> libraries\code\common\itkwin32header.h(23) : fatal error C1083:  
>>>>> Cannot
>>>>> open include file: 'itkConfigure.h': No such file or directory
>>>>>
>>>>> How do I fix this?  I can't find the itkConfigure.h file anywhere;
>>>>> does cmake not make it automatically?
>>>>>
>>>> Yes, that should be inside the build tree. I have my ITK source at
>>>>
>>>> X:\CMakeBase\Libraries\ITK-3.16
>>>>
>>>> and the build tree at
>>>>
>>>> X:\32Bit\VC.80\Libraries\ITK-3.16
>>>>
>>>> and I can see a itkConfigure.h in that folder.
>>>
>>> I've found it, and now I get:
>>>
>>> 1>c:\users\mark\src\itktests\itktestproject\itk
>>> libraries\code\common\itkmacro.h(42) : fatal error C1083: Cannot  
>>> open
>>> include file: 'vnl/vnl_math.h': No such file or directory
>>>
>>> vnl_math is not found in this directory structure.
>>>
>>> More to the point, I really have no desire to chase down ten  
>>> thousand
>>> header files to make this work; I strongly suspect that once the
>>> vnl_math.h problem gets fixed, then there's five others waiting in  
>>> the
>>> wings.  It's not at all clear to me why it is necessary to include
>>> math libraries just to create a blank 3D image, but setting aside my
>>> own ignorance, is there an easy way to get what I want, ie, just
>>> linking to some monolithic directory that has all the itk libraries?
>>> If not, if I wrote such a thing, would it be considered at all  
>>> useful
>>> by anyone else, or just the intransigence of one guy going against  
>>> the
>>> CMake trend?
>>>
>>> And what about those warnings?
>>>
>>> Thanks,
>>> Mark
>>
>> I _know_ you know what I am about to say, but I'll run down what  
>> you are
>> faced with.
>>
>> ITK uses the style of includes as "#include "itkImage.h" with out any
>> indication of what subfolder itkImage.h resides in. This means that  
>> _every_
>> subfolder in the ITK installation/source needs to be "included" in  
>> the
>> compile command. This looks something like the following (on OS X).
>>
>> cd /Users/mjackson/Workspace/AIMBlades/Build/AIM/SymmetryFilter &&
>> /usr/bin/c++   -DDEBUG -DQT_DLL -DQT_GUI_LIB -DQT_CORE_LIB -DQT_DEBUG
>> -ftemplate-depth-50 -Wall -Wno-deprecated -no-cpp-precomp -msse2
>> -fmessage-length=0 -g
>> -I/Users/Shared/Toolkits/ITK-3.14.0_Rel/include/InsightToolkit/Review
>> -I/Users/Shared/Toolkits/ITK-3.14.0_Rel/include/InsightToolkit/gdcm/ 
>> src
>> -I/Users/Shared/Toolkits/ITK-3.14.0_Rel/include/InsightToolkit/gdcm
>> -I/Users/Shared/Toolkits/ITK-3.14.0_Rel/include/InsightToolkit/ 
>> Utilities/vxl/core
>> -I/Users/Shared/Toolkits/ITK-3.14.0_Rel/include/InsightToolkit/ 
>> Utilities/vxl/vcl
>> -I/Users/Shared/Toolkits/ITK-3.14.0_Rel/include/InsightToolkit/ 
>> Utilities/vxl/v3p/netlib
>> -I/Users/Shared/Toolkits/ITK-3.14.0_Rel/include/InsightToolkit/ 
>> Utilities
>> -I/Users/Shared/Toolkits/ITK-3.14.0_Rel/include/InsightToolkit/ 
>> Utilities/itkExtHdrs
>> -I/Users/Shared/Toolkits/ITK-3.14.0_Rel/include/InsightToolkit/ 
>> Utilities/nifti/znzlib
>> -I/Users/Shared/Toolkits/ITK-3.14.0_Rel/include/InsightToolkit/ 
>> Utilities/nifti/niftilib
>> -I/Users/Shared/Toolkits/ITK-3.14.0_Rel/include/InsightToolkit/ 
>> Utilities/expat
>> -I/Users/Shared/Toolkits/ITK-3.14.0_Rel/include/InsightToolkit/ 
>> Utilities/DICOMParser
>> -I/Users/Shared/Toolkits/ITK-3.14.0_Rel/include/InsightToolkit/ 
>> Utilities/NrrdIO
>> -I/Users/Shared/Toolkits/ITK-3.14.0_Rel/include/InsightToolkit/ 
>> Utilities/MetaIO
>> -I/Users/Shared/Toolkits/ITK-3.14.0_Rel/include/InsightToolkit/ 
>> SpatialObject
>> -I/Users/Shared/Toolkits/ITK-3.14.0_Rel/include/InsightToolkit/ 
>> Numerics/NeuralNetworks
>> -I/Users/Shared/Toolkits/ITK-3.14.0_Rel/include/InsightToolkit/ 
>> Numerics/FEM
>> -I/Users/Shared/Toolkits/ITK-3.14.0_Rel/include/InsightToolkit/IO
>> -I/Users/Shared/Toolkits/ITK-3.14.0_Rel/include/InsightToolkit/ 
>> Numerics
>> -I/Users/Shared/Toolkits/ITK-3.14.0_Rel/include/InsightToolkit/Common
>> -I/Users/Shared/Toolkits/ITK-3.14.0_Rel/include/InsightToolkit/ 
>> BasicFilters
>> -I/Users/Shared/Toolkits/ITK-3.14.0_Rel/include/InsightToolkit/ 
>> Algorithms
>> -I/Users/Shared/Toolkits/ITK-3.14.0_Rel/include/InsightToolkit/ 
>> Numerics/Statistics
>> -I/Users/Shared/Toolkits/ITK-3.14.0_Rel/include/InsightToolkit
>> -I/Users/Shared/Toolkits/tiff/include
>> -I/Users/Shared/Toolkits/boost-1_39/include/boost-1_39
>> -I/Users/mjackson/Workspace/AIMBlades/Build
>> -I/Users/mjackson/Workspace/AIMBlades/Source
>> -I/Users/Shared/Toolkits/Qt-4.5.3-UBFramework/include
>> -I/Users/mjackson/Workspace/AIMBlades/Source/AIM/SymmetryFilter/ 
>> optimized
>> -F/Users/Shared/Toolkits/Qt-4.5.3-UBFramework/lib
>> -I/Users/mjackson/Workspace/AIMBlades/Source/AIM/SymmetryFilter/debug
>> -I/Users/Shared/Toolkits/Qt-4.5.3-UBFramework/include/QtGui
>> -I/Users/Shared/Toolkits/Qt-4.5.3-UBFramework/include/QtCore   - 
>> Wall -o
>> CMakeFiles/FourFoldSymmetry.dir/main.cpp.o -c
>> /Users/mjackson/Workspace/AIMBlades/Source/AIM/SymmetryFilter/ 
>> main.cpp
>>
>> And then the link command looks something like this (OS X example)
>>
>> cd /Users/mjackson/Workspace/AIMBlades/Build/AIM/SymmetryFilter &&
>> /Users/Shared/Toolkits/CMake-2.6.4/bin/cmake -E cmake_link_script
>> CMakeFiles/FourFoldSymmetry.dir/link.txt --verbose=1
>> /usr/bin/c++     -ftemplate-depth-50 -Wall -Wno-deprecated -no-cpp- 
>> precomp
>> -msse2 -fmessage-length=0 -g -Wl,-search_paths_first
>> -headerpad_max_install_names -fPIC
>> CMakeFiles/FourFoldSymmetry.dir/main.cpp.o  -o
>> ../../Bin/FourFoldSymmetry_debug
>>  -F/Users/Shared/Toolkits/Qt-4.5.3-UBFramework/lib
>> -L/Users/Shared/Toolkits/ITK-3.14.0_Rel/lib/InsightToolkit
>> -L/Users/Shared/Toolkits/boost-1_39/lib ../../Bin/libMXALib_debug.a
>> ../../Bin/libFourFoldSymmetryLib_debug.a
>> /Users/Shared/Toolkits/boost-1_39/lib/libboost_program_options- 
>> xgcc42-mt-d-1_39.a
>> ../../Bin/libMXALib_debug.a
>> /Users/Shared/Toolkits/tiff/lib/libtiff_debug.dylib -framework QtGui
>> -framework Carbon -framework AppKit -framework QtCore /usr/lib/ 
>> libz.dylib
>> -framework ApplicationServices -lITKAlgorithms -lITKNumerics - 
>> lITKStatistics
>> -litkNetlibSlatec -lITKFEM -lITKBasicFilters -lITKIO -lITKNrrdIO - 
>> litkgdcm
>> -litkjpeg12 -litkjpeg16 -litkopenjpeg -framework System -litkpng - 
>> litktiff
>> -litkjpeg8 -lITKSpatialObject -lITKCommon -litkvnl_inst -litkvnl_algo
>> -litkv3p_netlib -litkvnl -litkvcl -lm -lpthread -lITKMetaIO -litksys
>> -lITKDICOMParser -lITKEXPAT -lITKniftiio -lITKznz -litkzlib -lm
>>
>>
>> So if you go _without_ CMake you will need to incorporate _all_ of  
>> those
>> includes and libraries into your own VS project.
>>
>> If you _do_ use CMake then all of that is done for you when cmake  
>> generates
>> the Visual Studio project. Your Choice. And there is no "right"  
>> answer. You
>> need to do what works for you.
>>
>> Hope some of that helped.
>> _________________________________________________________
>> Mike Jackson                  mike.jackson at bluequartz.net
>> BlueQuartz Software                    www.bluequartz.net
>> Principal Software Engineer                  Dayton, Ohio
>>
>>

More information about the Insight-users mailing list