[MINC-development] MINC musings.

[Steve ROBBINS]

On Wed, Aug 13, 2003 at 01:46:52PM +1000, Andrew Janke wrote:
> 
> Whilst in the process of fixing the mincstats bug (patch to follow shortly) I
> noted that my CVS repo if MINC was waaay out of date and updated.
> 
> I note the build process has been revamped again (Master Robbins no doubt :),

It was Bert who did the major work in automakification; I helped out
where I could.  For one example, I've added a few more test cases
to ensure fixed bugs don't reoccur.


> 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.



> what are the conditions that are going to be needed to be met to 'allow' a new
> addittion to the base MINC stable?  Previously this sort of fell upon peter,
> him being the MINC grand-poo-bar and all that.
> 
> A vote?  anarchy?

I expect that, if someone made a specific proposal, we could come
to consensus on this list.  We've been more or less doing that for
the minor bug fixes over the last while.


Before we get to your soapbox speech, let me insert two of my
own:

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).

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.

 
 
>   * 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?


>   * I'm the first to admit I don't indent (code) as others do. I'm
>      also the first to admit that the indenting in both minccalc and
>      mincstats is pretty ugly. So is it possible that we can define
>      a default indenting style for all MINC code before it is submitted?
>     I have attached my own .indent.pro file that I attempt to use for
>      most of my other CVS code /s/s/minc_dev but sadly I didn't use
>      indent on the mincstats, minccalc as I just mailed the initial
>      hacks to peter and he included them.

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

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.


-S