From: malmberg@eisner.decus.org
Sent: Friday, January 26, 2001 7:22 PM
To: Info-VAX@Mvb.Saic.Com
Subject: Re: samba 2.0.6

In article <Oozvf8elmJpy-pn2-YTIHEoGMLBCG@Tom2>,
Thomas.Hahnemann@nospam_s-t.de (Thomas Hahnemann) writes:
> Now it compiles and link frontport.
>
> I've unpacked SAMBA_VMS_SOURCE_2_0_6_JEM_1.ZIP over
> SAMBA_SOURCE_2_0_6.ZIP. It compiles. But it breaks
> during linking :
>
> Linking LCL_BIN:UBIQX.EXE_AXP
> LINK /share=LCL_BIN:UBIQX.EXE_AXP  smb_ubiqx:ubiqx_AXP.opt/opt,
> lcl_bin:ubiqx.OLB_AXP/lib
> %LINK-F-OPENIN, error opening DATEN2:[SAMBA.SOURCE.BIN]UBIQX.OLB_AXP; as
> input
> -RMS-E-FNF, file not found
> %MMK-F-ERRUPD, error status %X1064109C occurred when updating target
> LCL_BIN:UBIQX.EXE_AXP
>
> I've looked into the samba.mms but I could not find any
> command for building UBIQX.OLB_AXP

Because SAMBA has so many files in each directory, I replaced the
"default" rule for compiling C programs with one that will also
put them in an object library that is named after the directory
the source module was found in.  The object library is stored in
lcl_bin:

If I had not done that, the SAMBA.MMS rules would have been extremely
large.  If you think they are bad now, just think of what it would
have been if I had had to specify a compiler action and a librarian
action individually for each of the files.

I left the other UN*X stuff in the MMS file because it does not hurt
and I thought it might make it easier to map to the order things
are in are in the UN*X makefile source for later versions.


To make this a rule based on the file name, the command procedure
SMB_SRC:add_to_library is run after the compile to parse out the path
that the source module came in on.


Because it is a multiple action rule, be aware that if there is a
compiler warning and MMS or MMK aborts, the object module will not
get put in the library.  And if the library does not exist, it will
not get recreated.


Information messages from the Compiler will not stop the build, nor
will they prevent the object library from being built.

The rule can be found by searching for ".c.$(O)" in the SAMBA.MMS
file.


For the few C modules that were not to be in object libraries, I
specified the action instead of letting it default to adding the
object module to a library.


So the dependencies for lcl_bin:ubiqx.$(EXE) are dependent on
$(UBIQX_OBJ) and $(UBIQX_OBJ) expands out to be the list of all
of the source modules.

I did not use a separate rule for inserting an object module in
a library if it was newer than the one that was in the library.
That has never worked reliably for me.


I would recommend deleting all lcl_ubiqx:*.obj_axp;* files and
running the MMK/DESCRIP=SMB_SRC:SAMBA.MMS again.

Something appears to have prevented all actions being taken
when the compile is done.

> In samba.mms I've added /WARN=DISABLE(UNUSEDTOP) to disable
> the often appearing "unused include" warning.

If that is a WARNING and not an Informational message, that
difference in the C compiler (I did not apply any ECOs) you
are using and the one I used could account for your build problem.

Any module that compiled with a warning and thus stopped the
SAMBA.MMS procedure from continuing will usually need it's
corresponding object file deleted.  You will find all the ones
that this happened to when you get to the link phase.

The longer term solution would probably to add the following
line to the config.h file.

#pragma message disable unusedtop

But your solution is good too.

Since all of SAMBA includes a file includes.h that includes almost
all the possible header files, it is verly likely that some of
the include files are not needed for a specific module.

-John
wb8tyw@qsl.network