[MINC-development] MINC musings.

[Andrew Janke]

On Wed, 13 Aug 2003, Steve ROBBINS wrote:

> > for a while now building minc has required automake/autoconf et al and
> > subsequently perl.
>
> No.  Building MINC requires none of the above.
>
> You, as a developer using CVS, need to have automake, autoconf, and libtool.
> The end-user of the tarball requires none of these.

Ah, IC.  The light finally dawns.

> 1. ChangeLog!  It's a great help for future MINC coders if you
> include a ChangeLog entry with every change.  Standard practice on
> other lists is to prepend your diff by the (NON DIFF) ChangeLog
> entry.  The idea is that the change log should give the reader
> the context in which to understand the diff.  (Otherwise, noone
> is likely to read and comment on it).

So you want a changelog entry posted before a CVS commit?  Sounds reasonable
enough to me.

> 2. Test cases.  Automake has some machinery to automatically run
> a test suite ("make check").  When a bug has been identified, it
> is good practice to first write a test that exposes the bug.  Wrap
> it in a shell script that returns an error code (nonzero).  Then
> fix the bug and run "make check" to ensure it is gone.  The beauty
> of the test suite is that -- since the developers always run
> make check before committing, right?? --- if the bug is ever
> accidentally reintroduced, it will be caught immediately.

Testing? Shmesting! :)   Orright, orright, I'll have a hack at writing a test
suite for mincstats.

> >   * Can we remove mincexample{1,2} from the base install/build or
> >      shove them in a separate ./dev/ directory? Considering the
> >      executables appear to be now built in ./
>
> The examples aren't installed.  Are you objecting to having them
> merely built in the toplevel directory?

Not really, just wondering how many people who build MINC realise they are even
there.  At least if they were in a ./dev directory (and if I ever get to
finishing my other voxel-loop examples) their purpose IMHO would be more
obvious.

> > indenting.
>
> I'm only going to say two things about this can of worms.
>
> 1. indentations must be 4 spaces per level (or 8 spaces per level).
>    It's just too hard to tell the difference between 2/4/6 or 3/6/9
>    when there are 20 or more lines of text in between

I can live with this.

> 2. If you're going to reindent things, YOU MUST make it a separate
>    cvs commit.  Do not include other changes along with indentation changes:
>    it is way too hard to read the diffs to figure out what is going on.
>    YOU MUST put a clear statement in the ChangeLog and in the cvs commit
>    message to the effect that this is only a change in indentation.

Done deal.

So do I make the changes to mincstats?  (After I figure out how to write a test
case! )

--
Andrew Janke   ( rotor@cmr.uq.edu.au || www.cmr.uq.edu.au/~rotor )
Australia->University of Queensland->Centre for Magnetic Resonance
W: +61 7 3365 4100  ||  H: +61 7 3800 4042  ||  M: +61 4 2138 8581