[Insight-developers] ITK tree layout

[Jim Miller]

I am not sure that I agreed.  But it is interesting.  I am trying to reconcile this design with how I used to and how I will in the future structure projects.

Here is what I do today:

If I have a project called Foo that uses ITK, then Foo has its own source code repository and it builds against ITK. So I checkout ITK. Build ITK. Checkout Foo. Configure Foo to tell it where ITK is. Build Foo.  This works fine for small projects.  But if I have a project that uses ITK and VTK and something else and another something else, then it gets to be a pain to describe to my developers and customers how they need to go about building the software.

Here is what Slicer does today:

Slicer uses quite a number of extra packages for its build process it authored to checkout, configure and build all the subpackages that it needs. In Slicer3 this worked great when it worked great and was hard to debug when something went wrong. Jury still out on Slicer4. I think its better but I have stumbled a few times.

Here is what I think Paraview used to do (not sure whether it still does).

Paraview relied on VTK so the source tree of Paraview would include a checkout of the version of VTK that it needed to use. No confusion for the user as to which VTK to use to build Paraview. Can't speak to how the build process worked.  This is a popular approach with product teams.

Here is what the new model will allow:

Create a branch of ITK. Add new modules next to ITK that are only checked into the branch. One repository and one build to build your new application. Simple. Nice. Easy to share with other developers. I could see a lot people using this approach to get started with ITK.

What I am uncomfortable with is someone accidentally merging this vendor specific code back into the main ITK tree. I could see this happen if we locally patch ITK to get around a bug and then try to push that patch back to ITK and we accidentally push our vendor specific code as well. This may not be good.

So while it sounds neat, I don't think I know enough about how to work with it yet to say that it is something that I would use all the time.  It may be something that I only use when working on an extension to ITK that I intend to make opensource as well (so I wouldn't worry about it leaking out if it did).

---

While I find the ITK/ITK structure weird for now, I do not have any issue with ITK being different in layout than VTK. After all, it has been different for 10 years since ITK has always had a "Code" directory and until recently "Testing" was a separate top-level directory instead of a subdirectory in each library.

Jim





On Mar 16, 2011, at 4:09 PM, Bill Lorensen wrote:

> and Jim agreed with Brad (I think):
> "The ITK/ITK sounded weird to me at first. I was actually wondering if
> it was a stopgap position until the rest of the toolkit was
> flushed-out (Examples, Tests).  But I think Brad's point of having the
> inner ITK directory parallel to custom directories is interesting.
> That was certainly how we used to structure things.  With CMake and
> recent advances in CMake, I am not sure this strategy is needed
> anymore.  "

Jim Miller
Senior Scientist
GE Research 
Interventional and Therapy

GE imagination at work

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20110316/6af57df5/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3108 bytes
Desc: not available
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20110316/6af57df5/attachment.bin>