On Tue, 6 Oct 1998, Frederick Bruckman wrote:

> On Mon, 5 Oct 1998, Bill Studenmund wrote:
> 
> > We either need to teach LOBJS how to find the files, or .NOPATH all the
> > things in LOBJS.
> > 
> > Would this work?
> > 
> > llib-l${LIB}.ln: ${LOBJS}
> >         @echo building llib-l${LIB}.ln
> >         @rm -f llib-l${LIB}.ln
> >         @${LINT} -C${LIB} ${.IMPSRC} ${LLIBS}
> 
> Maybe, but why give the "linted" stamp of approval on only libraries
> that pull in sources from other directories? Why not regular binaries,
> too? ;)

Actually, that doesn't work. I tried it unsuccesfully after sending the
message.

> There's one more possibility. Is there any reason that libkafs can't
> link against libkrb? That would allow libkafs to use the function
> without any "make" magic. Just a thought.

Problems:

1) Our build tools don't deal well w/ libraries which link against other
libraries when you're in a DESTDIR environment. The fix is easy (add
-L$DESTDIR/usr/lib -nostdlib if you're DESTDIR'ing), but seems gross to
folks. Well, everyone I've shown it to dislikes it. :-) Right now, we have
no libraries with this problem.

2) Removing get_in_tkt from libkafs would require bumping the major
number. The whole point of this effort was to prevent that.

3) Our shared libraries, at least a.out ones, don't deal well w/ libraries
depending on other libraries. It doesn't auto-include them.

In your other message you suggested fixing the lint command to deal as
well with PATHing as ar does. I think that's the best idea.

I just tried this, and it seems to work. Does it work for you?

Could some other make folks peek over my shoulder to double check this?

llib-l${LIB}.ln: ${LOBJS}
        @echo building llib-l${LIB}.ln
        @rm -f llib-l${LIB}.ln
        @${LINT} -C${LIB} ${.ALLSRC} ${LLIBS}

Take care,

Bill