[Insight-developers] Musings on new modularization

[Bill Lorensen]

On Sat, Mar 12, 2011 at 7:54 PM, Johnson, Hans J <hans-johnson at uiowa.edu> wrote:
> First: I understand that modularization will eventually have benefits, and I
> am not opposed to it.  I loved my old comfortable ITK, and this new version
> is certainly going to take some time to get used to.
> I do have a few observations that may/may not be addressable:
> 1)  Bad.  The path to code has a repeated name "src/ITK/ITK/Core/Common"
>  Note the ITK/ITK.  This makes it difficult to comminicate with other
> developers verbally when trying to work through problems.  "Goto the upper
> level ITK directory" "Goto the nested ITK directory below the ITK
> directory".   Perhaps this directory could be renamed back to Code, or some
> other unique name.  This should be done quickly before the developers
> fingers learn this pattern.  This is also annoying, because my shell prompt
> shows me the directory name that I am currently in, and with replicated
> naming scheme my current working directory displayed is now ambiguous.
> 1a)  There is "ITK/Utilities" and there is "ITK/ITK/Utilities" .  These
> should also be made unique.  Perhaps "ITK/BuildUtilities"

I agree 100%. ITK/ITK is cumbersome. Will VTK be using VTK/VTK/


> 2) Unfortunate, but probably necessary.   Using grep to find items has
> become more tedious with the new "bush" structure, where the previous "tree"
> had fewer places to look. Not bad, and it is probably more annoying for
> those of us who have the ITK tree navigation imprinted as involuntary
> reflexes rather than conscious thought.   After re-trainging the new
> structure will likely make it easier to find items.

Agree, unfortunate but necessary.

> 3)  Undecided.  Things are modular!  There used to be a nice fully connected
> build tree where one could select a branch and build everything under that
> branch.  This is no longer the case.  Upon entering the "Utilities"
> directory, I issued a make command, and was surprised that there was no
> Makefile there!  I see why this is the case, and perhaps someday I'll even
> appreciate this, but I was surprised by this and it will  require a change
> of work habits.

I also agree. We should be able to go into a module and type make.

> 4) Good.  This is a good "annealing" code optimization process.  Shake
> things up and get us out of the local minima that we've been in for a while.
>  It is exposing some areas that where sloppy.  Honestly, considering the
> HUGE disturbance and the magnitude of massive change that just occurred, the
> smoothness of the transition so far is a testament to the quality of our
> overall processes and attention to detail.  We deserve a pat on the back for
> this.

Disagree. I think we have a way to go before things are back to
"normal". The devil is in the details.

> 5) This has always been there, but  it is more exposed now.   Do we really
> need all these different versions of the JPEG library?
> Utilities/OpenJPEG vs Utilities/JPEG vs GDCM/jpeg
> Food for thought.
> Hans