[Insight-users] Loading DICOM RTStructs

[Mark Roden]

Hi Luis,

On Wed, Oct 21, 2009 at 2:59 PM, Luis Ibanez <luis.ibanez at kitware.com> wrote:
> Hi Mark,
>
>
> 1) Please log a bug ("Feature Request") In the MANTIS bug tracker:
>
>          http://public.kitware.com/Bug/my_view_page.php
>
>    To requesting the modification of the ITK installation procedure to
>    use a single flat directory instead of the current set of subdirectories.
>
>     I agree with you in that, this will make easier to use ITK from
>     external project, even in the cases where they use CMake
>     for configuration.
>
>     We don't have headers with duplicate names (as far as I know)
>     so name collisions shouldn't be an issue.

Thanks, I'll head over there now.

>
>
> 2) You may find useful to read the tutorial:
>
>               http://www.itk.org/ITK/help/tutorials.html
>
>     in particular:
>
>     http://www.itk.org/CourseWare/Training/GettingStarted-I.pdf
>
>     It will show you how to create a HelloWorld example from
>     scratch.
>
>     The same procedure is explained in the initial chapters of
>      the ITK Software Guide
>
>             http://www.itk.org/ItkSoftwareGuide.pdf
>

I was using the 'getting started' from the manual, and the HelloWorld
code from that.  Both examples are still CMake-based, which is OK, but
not what I want.

>
>
> 3)  I don't see why you would need to include "itkConfigure.h"
>     in any program that uses ITK.
>
>     If you have found that to be needed, you may be dealing
>     with a larger configuration issue.
>
>     Normally, including headers such as "itkImage.h" should
>     do the trick.
>
>     You may find useful to look at the many examples in the
>      directory:
>
>                             Insight/Examples/
>

When I:
1) build the install directory (CMake, shared libraries on and nothing else)
2) Create a new sln (vs2008, new project, C++, win32 console app)
3) point to the itk/headers/common directory (additional include directories)
4) #include "itkimage.h"
5) build
I get an error stating that itkconfigure.h could not be found.  If I
then include that directory, I get another error that vnl_math.h could
not be found.  If I'm doing something wrong, I'll happily correct my
procedure, but that's how I thought things should be done.  Once the
directory structure gets flattened, that would seem like the way to do
things.

>
>
> 4)  You may understand better the advantages of using CMake
>     when you are confronted with the following scenarios:
>
>        A)    Moving your project from one computer to another,
>               (even when they have identical operating systems
>                 and build environments).

I solve this problem by requiring that my projects always be buildable
from source code.  If the project cannot be checked out, built, and
then run entirely from a command line script, then it is broken.
CMake is one way to solve this problem, MSBuild is another.  I'm used
to MSBuild.

>
>        B)    Building your project in two (or more) different
>                platforms.

True.  I've done this as well, and have found that for the most part,
when using native libraries, there needs to be some native code
calling on the UI side.  Something like Qt may solve this issue, but
when I first tried Qt it didn't have the UI widgets I needed and I
haven't returned.  So, with that experience in hand, the team I was on
had a large portion of the code was uniform across platforms, and some
was Windows and some was Mac.  The unfortunate reality was that that
did cause development to be lopsided in some features to one platform
over another, but at the time, it was the best solution we had because
the UI coding was so different and there wasn't a solution like Qt.
Now, with Qt, I'd still just have the code in one place and buildable,
and something like CMake may help, but I'm not in that environment at
the moment.

>
>         C)   Building projects that have dependencies on
>                many third party libraries.
>

When I do this, I check the libraries into the source repository, and
just have cascading builds.  If I have the source for those libraries,
great, then I can build them when a new version comes out, but for the
most part, the libraries are unchanged over the time I change my code,
so that the possibility of the interaction failing is minimized. So,
with the libraries checked into source, and the source required to
build from the command line at any given time not to be broken, this
requirement is also fulfilled.

It's just a different way to skin the cat.  I understand why itk does
use CMake, because I don't support more than a single platform at a
time, and I could see how modern UI widgets available across all UIs
could make it possible to have a single unified codebase.

>
>      Of course, you are not forced to use CMake in order to
>      take advantage of ITK.
>

And that is exciting to me, as I'm sure you can tell :)

Thanks,
Mark

>
>
>   Regards,
>
>
>          Luis
>
>
> -------------------------------------------------------------------------
> On Wed, Oct 21, 2009 at 1:29 PM, Mark Roden <mmroden at gmail.com> wrote:
>> Hi Luis,
>>
>> Thanks for the help, but I'm still having problems.  Namely, the
>> headers continue to be scattered throughout a directory tree rather
>> than in one big folder.  I'll just do that by hand, I suppose.  But
>> the include directory should be flat.  If there are headers that are
>> named the same thing, then they should have different names just to
>> avoid collisions in general.
>>
>> Here's the thing.  You compare ITK to STL, and it's STL that I'm
>> thinking of.  There, when I #include <vector>, I don't also have to
>> #include <algorithm> until I need an algorithm.  If I #include
>> <itkimage.h> then I also need to include itkConfigure.h and then that
>> needs vnl_math.h and then... and so forth, and they're all in
>> different directories.  I want to be able to include the headers I
>> need, but just point to one place to use that header, rather than
>> pointing to a nested directory structure.  The structure can remain
>> nested on the development side; that's entirely irrelevant to me.  But
>> for the sake of ease of use, if it's all in one flat directory, then I
>> don't need to learn Yet Another Build Tool (CMake), and can just
>> include that directory and be done.
>>
>> I want to start from a blank slate project, where HelloWorld.cpp and
>> HellowWorld.h are just there, and nothing else.  Instead, HelloWorld
>> is surrounded by a bunch of other projects, and it's not at all clear
>> how to make a new project that's entirely empty.  I don't even see a
>> HelloWorld.h, and that weirds me out.  Within this separate project, I
>> am now free to Do My Own Thing and impose whatever stylistic
>> guidelines I want, anything from source control, unit tests, class
>> organization, etc.  I don't like being tied to CMake as a tool because
>> I don't see how it's necessary to get the job done, I just see it as a
>> convenience for making the library.  Once the library is made, the
>> tools to make it should get out of the way and let me do my thing.
>>
>> Thanks,
>> Mark
>>
>