rick@bnrunix.UUCP (Rick Johns) (11/18/89)
Hi. I'm having trouble understanding something, or maybe it's just trouble
believing something.
When compiling a Pascal module that IMPORTs another module, it's necessary to
use a $SEARCH$ compiler directive to tell the compiler exactly where to find
the object code for the IMPORTed module. So, if module X IMPORTs module Y, the
$SEARCH$ directive in X might be:
$SEARCH 'Y.o'$
However, if I want to keep IMPORTed files in a central library someplace but
still be able to compile Y locally (on occasion), I need something like:
$SEARCH 'Y.o', '/stuff/Ylib.a'$
Now, though, the compiler still insists on finding Y.o, even though it might
not be around. Y is still in Ylib.a, so what's the problem? I can think of a
number of kludges to get around this, but they're all real ugly. Anyone have
a graceful solution?
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? I saw something about
guaranteeing that modules don't use each other (Y has to be compiled already
when X is compiled, so Y can't use X) but it's hard to believe that this is the
only way to do it. The source code should not contain pathnames of object
files. It's ludicrous.
Thanks in advance--
Rick Johns
BNR
Research Triangle Park, NC
(919)991-7191
rti!bnrunix!rick@mcnc.org
uunet!mcnc.org!bnrunix!rick@uunet.UU.NET
rjohns@bnr.ca
================================================================================
The word is "its". "It's" is something else entirely.
================================================================================
Disclaimer: These opinions are mine and not BNR's.bigelow@hpfcso.HP.COM (Jim Bigelow) (11/21/89)
Have you tried reversing the files in the search path? e.g., $search 'lib1.a,lib2.a,...,foo.o'$ This way libraries are used first to resolve imported modules. Jim Bigelow S300 Pascal Colorado Language Lab. Hewlett Packard