Re: [mtools] Mtools 3.9.10 for VMS

[Alain Knaff]

Steven M. Schweda wrote:
>    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.

Ok, for the spelling correction.

Not ok for gratuitious whitespace changes. Indeed, these just introduce 
clutter in the diff, and make your patch hard to read and evaluate...

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

The trouble is, this might break compilation on Unix.

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

Ok, I think in this situation, it's indeed preferable to put these into 
a directory of their own, rather than the main directory. Initially, I 
was more thinking along the lines "if we could eliminate those files 
altogether". But if they are indeed needed, it is indeed preferably to 
keep them in a subdirectory of their own rather than clutter the main 
directory.

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

If these are files that are supposed to be generated during compilation, 
please DON'T include them in the diff.

If on the other hand, they are supposed to exist before the compilation 
(autoconfig/autoheader-style stuff), then do include them

Thanks,

Alain

_______________________________________________
mtools mailing list
address@hidden
http://www.tux.org/mailman/listinfo/mtools