[MINC-development] MINC musings.
Andrew Janke
minc-development@bic.mni.mcgill.ca
Thu, 14 Aug 2003 10:25:50 +1000
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