MMS object library rules

[Aaron Sakovich]

I'm trying to get an MMS dependency rule to allow me to put a bunch of object files into an object library. Sounds simple, but I've got a BUNCH of object files. So many so that when the original code ran, it would choke with an EXETOOBIG error in MMS (exceeded the length of the command line).

I've read the docu (many times now) and scoured the web for a good example, but haven't really found one. The closest I've come to getting it to work is shown by this example:

=-=-=-=-=-

lib$:oblib(after_log=obj$:after_log.obj) : obj$:after_log.obj

lib$:oblib(ascii=obj$:ascii.obj) : obj$:ascii.obj

lib$:oblib(c$brk=obj$:c$brk.obj) : obj$:c$brk.obj

lib$:oblib(c$bksp=obj$:c$bksp.obj) : obj$:c$bksp.obj

lib$:oblib(c$grep=obj$:c$grep.obj) : obj$:c$grep.obj

(and on for many more objects...)

=-=-=-=-=-

(And yes, there are dependency rules further down in the file for building the OBJ files from their various sources.)

However, when I try to run MMS with this descrip, it adds the first module (after_log) and then ends. If I try to run it again, it says the library is up to date, even though that's the only module in the library!!!

From what the docu said, I interpreted it to mean that such would happen if I specified the object library as the target, and I would avoid this problem if I used the above module references.

It seems I'm not groking this properly. Help?

Aaron

[Steven Schweda]

I believe that this is covered in the MMS
manual somewhere, but you seem to have
described how the modules in the library
depend on the individual object files, but
not how the library depends on its modules.

I'd've expected a ".olb" on "oblib", but you
might toss in something like:

oblib_mods = after_log=obj$:after_log.obj \
ascii=obj$:ascii.obj \
c$brk=obj$:c$brk.obj \
[...]

lib$:oblib : lib$:oblib($(oblib_mods))
@ write sys$output "$(MMS$TARGET) updated."

There must be a lot of examples of this stuff
floating around, but the smallest one I can
find right now is in the Zip 3.0e BETA kit:

ftp://ftp.info-zip.org/pub/infozip/OLD/beta/zip30e.zip

The stuff is all in [.VMS]descrip*.mms.

It's a bit more complicated than the ideal
for instructional purposes, with more layers
of macros, but I believe that it works.

Prompt complaints would certainly be welcome,
if not.

[Craig A Berry · Accepted solution]

I'm not sure this adds much to what Steven said, but what I've seen done is something like:

mylibobjs = foo.obj, bar.obj, baz.obj

mylib.olb : mylib.olb( $(mylibobjs) )
library/compress $(MMS$TARGET)/output=$(MMS$TARGET)


That gets you a compressed version of the library that is better for distribution purposes.

If the macro mylibobjs blows up some buffer by getting too long, I think you'd just have to break it in chunks and make the library dependent on two, three, or however many lists of object files, though I'm not completely sure that would work since I've never tried it.

[Malleka Ramachandran]

There is an example in the MMS guide towards the end, it is called advanced (or complex, something to that effect), where a complete build process for a product is defined. I used it to create my MMS file and it works. Following this example, I use OBJ_LIB in the dependency rule.
Example:
.OBJ.OLB :
@ IF F$SEARCH("$(MMS$TARGET)") .eqs. "" then -
$(LIBR)/CREATE/LOG $(MMS$TARGET)
$(LIBR) $(LIBRFLAGS) $(MMS$TARGET) $(MMS$SOURCE)

OLB_ELEMENTS = -
A32=OBJ$:A32.OBJ ,-
...

OBJ$:XXX.EXE : OBJ$:XXXMAIN.OBJ OBJ$:XYZ3300.OLB,SRC$:XXX.OPT
LINK/map/exe=obj$:XXX.EXE OBJ$:XXXMAIN.OBJ,XYZ3300.OLB/LIB,SRC$:XXX.OPT/OPT
OBJ$:XXXMAIN.OBJ : SRC$:XXXMAIN.C
$(CC) $(CFLAGS) /OBJ=$(MMS$TARGET) $(MMS$SOURCE)
OBJ$:XYZ3300.OLB : OBJ$:XYZ3300.OLB($(OLB_ELEMENTS))
CONTINUE
...
OBJ$:A32.OBJ : SRC$:A32.C
$(CC) $(CFLAGS) /OBJ=$(MMS$TARGET) $(MMS$SOURCE)

[Aaron Sakovich]

Yup, that got it. It didn't appear as clear as your examples to me, for some reason. I defined a macro with the whole list of obj's, and then set the library to be dependent on the modules in the library as referenced by the macro.

Thanks for your help. Maintenance of someone else's code is a royal pain in the nether regions, but having your help here saved me hours of futzing around!

Aaron

[Steven Schweda]

> I defined a macro with the whole list of
> obj's, [[_not_ library modules]] and then
> set the library to be dependent on the
> modules [[no, _object files, _not_]] in the
> library as referenced by the macro.

So, when the object files are all made, and
then the object library is created, it'll be
newer than any of the object files, so
there'll be no need to add them to the
library.

It's critical to say that the library depends
on the _modules_ in the library, not on the
loose object files. It's a bit quirky, but
that's how it's done. And some sort of
null/harmless action is required for that
rule, to satisfy the syntax requirements.

[Aaron Sakovich]

There seems to be proper processing of modules and libraries using the default .olb.obj rules.

Where I'm stuck now is with one of the obj files that go into my olb; it has a module name different than the object file name. Ordinarily, that wouldn't be a big deal, but in this case, the module name is .MAIN. and MMS is choking on the ersatz periods. With the following in my olb dependency:

[mumble},.MAIN.=sub.obj,{moremumble}

I get the following error

%MMS-F-LBRNOELEM, Illegal library element is specified in LIB$:07LIB.OLB

I can issue the corresponding library command at the $ prompt sans err:

$ Libr/repl ObLib.olb sub.obj/module=.MAIN./Log
%LIBRAR-S-REPLACED, module .MAIN. replaced in DEV:[LIB]OBLIB.OLB;1

I've scoured the docu (again) and the web and newsgroups and ITRC and AskQ (or whatever it's called now) to no avail.

So, how am I supposed to spec a module with periods in its name?

Curious,
Aaron