[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [mtools] Mtools 3.9.10 for VMS
Re: [mtools] Mtools 3.9.10 for VMS
Thu, 22 Jun 2006 17:31:30 +0200
Thunderbird 1.5 (X11/20051201)
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
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,
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
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
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
mtools mailing list