FW: [Insight-developers] Build Errors: AffineTransform, MRASlabIdentifier,GibbsPriorFilter, QuaternionRigid

[Bill Hoffman]

Ok, so you checked in some code just to see if it would work on other compilers.
Perhaps there is a better way to do that.

1. You could email the code in question to Brad or myself and we could
try it on several compilers before you check it in.

2. you could create a single example in insight that uses the same sort of
c++ and wait and see if that works on all the compilers.


I guess I would expect that most of the time code checked in, would compile
on at least one compiler.

At 02:22 AM 8/17/2001 -0400, Luis Ibanez wrote:


>Bill,
>
>The refactoring of the RegistrationTransforms was a major change,
>it involved more than 70 files, and some changes in the
>RegistrationFramework. It took more than a week from the
>introduction of the first modifications until the dashboad was stable
>again.  The error caused by the absent itkQuaternionTransform class
>is the remanent of about a thousand errors produced in the first days.
>So from a wide perspective this remanent error is probably not that bad.
>
>The files where checked in before the re-factoring was finished
>because is quite hard to ensure that the new versions will be
>acceptable on all our platforms, and the Dashboard is the best
>(and maybe the only) way to verify this consitency.
>
>Thanks to checking in the partial re-factoring, incompatibilities
>between SGI/WinNT/gcc where detected early in some of the transforms
>before the same changes were done in the rest of them, and even
>with that help, several iterations where required to get a combination
>that satisfied all the compilers.
>
>I agree with the rule that things should be fixed rapidly, but
>with refactoring is not easy to anticipate how long it will
>take to get rid of all the errors.
>
>The rigid transform will still pass through a couple of changes, and
>they will affect all the registration methods in the toolkit.
>
>I like your proposal of automatically receiving mail for errors we
>introduce in the Dashboard, it will be a great help in getting rid of
>errors in a rapid way.
>
>
>Luis,