Path: utzoo!utgpu!attcan!uunet!aplcen!uakari.primate.wisc.edu!brutus.cs.uiuc.edu!psuvax1!rutgers!ucsd!ucbvax!hplabs!hpfcso!steve-t
From: steve-t@hpfcso.HP.COM (Steve Taylor)
Newsgroups: comp.sys.hp
Subject: Re: Separate Compilation With HP/UX Pascal
Message-ID: <7370038@hpfcso.HP.COM>
Date: 19 Nov 89 00:19:59 GMT
References: <416@bnrunix.UUCP>
Organization: Hewlett-Packard, Fort Collins, CO, USA
Lines: 31

} / comp.sys.hp / rick@bnrunix.UUCP (Rick Johns) / 4:12 pm Nov 17,1989 /
} While I'm on it, what is the advantage to this?  Why can't I just specify
} on the command line what libraries and object files to link in?  ....
} ....  The source code should not contain pathnames of object files.
} ----------

I haven't used Pascal on HP-UX yet, but I believe it is similar to Pascal
on the Pascal Workstation, so I'll say a few words based on that.  I'm sure
someone will correct me if it doesn't apply to HP-UX Pascal.

An unlinked object file from the Pascal compiler contains, in addition to
the usual object code, a section of ASCII text which is the EXPORT section
of the original module.  The use of $SEARCH in conjunction with INPORT
tells the compiler which object file to read this source text from.

On one project I worked on, we keep the source text for the EXPORT sections
of the modules in separate files, which we would $include where needed.

These two approaches are equivalent, because in both cases the compiler is
reading the source text to get the externally visible definition of the other
modules.  It's just that in one case it's reading the source from an obvious
source file, and in the other ($SEARCH) it's reading the source text from
an object file (where another compile previously copied it).

I'm afraid I don't know the answer to your operational question, but I hope
this will help explain why this is not equivalent to linking in C object
files (say).  It's more like #including header files.

						Regards, Steve Taylor

NOT A STATEMENT, OFFICIAL OR OTHERWISE, OF THE HEWLETT-PACKARD COMPANY.