forrest@blia.BLI.COM (Jon Forrest) (08/14/87)
I've used MMS a lot in the last year. The problems reported about it
recently aren't the ones that bother me. Instead, the following are
the deficiencies I've found with it. I'd like to point out that my opinion
of MMS isn't as bad as that of certain people. It works reliably and is
fast enough for me. I do agree that the documentation leaves a lot
to be desired.
1. There should be a macro like the existing MMS$CHANGED_LIST macro
but one that does NOT include the file types in the list. If this
macro were to exist then it would be possible to compile many
source files with one command, and then to insert the newly
created object files into a library with one command. For
example, assume the macro I'm asking for is called
MMS$CHANGED_NEW. Then the following would result in one
CC command and one LIBRARIAN command.
a.olb : x.obj, y.obj, z.obj ! this could be ANY number of files
cc MMS$CHANGED_NEW ! compile them all
librarian/replace MMS$TARGET_NAME MMS$CHANGED_NEW ! insert them all
Currently it is necessary to invoke the compiler and librarian once for
each file to be compiled and inserted in the library. This is a waste of
resources since the compiler and librarian actually need be started only once.
In a situation where a hundred source files are to be compiled this extra
overhead could be considerable.
2. It should be possible to make a rule that says that a library module depends
on a source file and not on the object file. Of course,
the object file would be required but the modification date
of the source file would be used to determine what has to be
rebuilt, not that of the object file. This would allow object
files to be deleted without disturbing the dependency information.
It seems wasteful to keep object files around after they are put in an object
library.
For example, the following expresses what I have in mind.
a.olb : a(x=x.c)
This means that the module named "x" is rebuilt when the
modification date of "x.c" is newer than the date "x"
was inserted in "a.olb". This assumes that the date "x.obj"
was inserted in "a.olb" was when "x.obj" was last modified.
This is especially important when a large number of object
files are kept in a library. Currently, all the object files
must be kept both in the library and as normal files. This is
wasteful.
3. There is an incompatability between MMS and Unix "make"
that isn't mentioned in the manual. "Make" allows description
files such as:
a : a.exe
a.exe : a.c
MMS gives the fatal GWKNOACTS message for the first line
since there are no builtin rules to satisify this
dependency. "Make" gives no error messages. I understand
why MMS might want to print a message in a situation like
this but this situation should not generate a fatal error.
4. A program being run from a MAKEFILE. finds that its
SYS$ERROR is a mailbox, and not the terminal from which
MMS is being run. This causes problems if the program being
run uses the terminal type of SYS$ERROR. At least, this
should be documented.
Jon Forrest
forrest@blia.BLI.COM
ucbvax!mtxinu!blia!forrest
{pyramid|voder}!blia!forrest