Re: [mtools] Mtools 3.9.10 for VMS

[Steven M. Schweda]

> From: Alain Knaff <address@hidden>

> Moritz Barsnick wrote:
> > [I'm not the original submitter of the changes!]
> > 
> > Hi,
> > 
> > I've prepared a patch forward ported from Steven's source to
> > mtools-3.9.10-20060531.

   I was just working on this myself.  I'll see if I can compare your
results with mine.  I've made a few minor changes to some of the
VMS-specific files in the "vms" directory, too.

> > Note: Apart from spelling fixes and whitespace fixes, there are also some
> > "functional" changes (typecasting, bracketing includes within #ifdef
> > HAVE_INCLUDE_H, and the likes). They look interesting, possibly correct,
> > but I assume they need review.
> 
> I'd rather keep the patch focused...

   Other than the spelling correction in a comment in mcopy.c, I believe
that all the whitespace changes were in files I was already changing for
some other reason.  I prefer spaces to tabs, so I normally tend to use
spaces without thinking.  As I was trying to follow the mtools
tab-indent style, I found it easier to change _all_ the space-indent
problems in these files to the tab-indent style, rather than try to fix
only _my_ space-indents and leave the old ones as they were.  Unless you
think it important for some reason to retain the errors and/or the
deviant space-indents, I really don't see the harm in making all these
changes now.

   All the added type-casts are the results of warnings from the
DEC/Compaq/HP C compiler(s), typically a mismatch between "int" and
"unsigned int" (or pointers to them).  It was easier and safer to add
the type-casts than to disable the warnings from the compiler. 
(Compiler warnings normally stop MMS (think "make") when building the
product, so the choice is to stop these compiler warnings or else to let
MMS sail on past all compiler/linker warnings, which would be foolish,
generally speaking.)

   Bracketting the "#include" directives with "#ifdef HAVE_INCLUDE_H"
was needed to avoid fatal compiler errors caused by trying to include
header files which don't exist here.  Except for the one spelling
correction in mcopy.c (and the indentation changes), all these changes
were made to allow this stuff to get built and run on VMS, not because I
didn't like the original coding style.

   In a private e-mail message, Alain also suggested not having the
"vms" directory.  I used it because:

   1. All the builders are different on VMS.  It would be fine with me
to put all the *.com and descrip*.mms files in the main directory, but
for most people, they would just be clutter.

   2. Similarly, the VMS-specific code (decc_ver.c, vms.c, vms.h,
vms_scsi.c) is _so_ VMS-specific, that most people will never want to
see it.

   3. Similar for the VMS-specific documentation.

But if you would prefer to have all this stuff in the main directory, it
should be easy enough to arrange things that way, instead.

   The manually generated config.h_vms would be pretty harmless
anywhere, I suppose.  As for maintenance, on the bright side, adding a
new source file to descrip_src.mms should be pretty easy, but the
automatically generated dependencies (descrip_deps.mms) would need to be
regenerated on a VMS system.

------------------------------------------------------------------------

   Steven M. Schweda               address@hidden
   382 South Warwick Street        (+1) 651-699-9818
   Saint Paul  MN  55105-2547
_______________________________________________
mtools mailing list
address@hidden
http://www.tux.org/mailman/listinfo/mtools