5 messages in com.perforce.jamming[jamming] Library rule quirks with LO...
FromSent OnAttachments
John...@nanaon-sha.co.jp30 Jun 2000 01:00 
Dave...@vignette.com03 Jul 2000 11:14 
Dian...@yahoo.com03 Jul 2000 20:07 
Dave...@creo.com04 Jul 2000 14:18 
Roesler07 Jul 2000 18:28 
Subject:[jamming] Library rule quirks with LOCATE
From:Dian...@yahoo.com (Dian@yahoo.com)
Date:07/03/2000 08:07:14 PM
List:com.perforce.jamming

I meant to reply to the guy who said this works for him, but I accidentally deleted it. I'd like to see how you're doing it to make it work.

The behaviour I see is exactly as John described. If you set LOCATE on the library target, it'll get put where you specify, but the object modules for it will recompile everytime, because they depend on a local library that doesn't exist (e.g., libfoo.a(foo.o)). The same is true if you use MakeLocate.

If a Library target is specified without a directory, the LibraryFromObjects rule calls MakeLocate with LOCATE_TARGET as the directory, which, if you're using SubDir, is set to the local directory, and if you're not using SubDir, is unset. So in either case, you end up with the target library being LOCATE on'd the local directory, and the object modules being dependent on that local library.

If you specify LOCATE (or LOCATE_TARGET) generically (as opposed to "on" the library target), you'll get the object modules depending on the right (full-path) library, but the modules themselves will be compiled into the directory the library goes in rather than in the local source directory (which probably isn't what you want, especially if you keep your objects, since you could potentially end up with name conflicts).

If you set KEEPOBJS, then the object modules become dependencies of "obj" and will get recompiled when necessary, but no dependency is set for the library $(l) on "lib", so the library is never built. This looks to be an actual bug. I'm not sure what the thinking was for the if on KEEPOBJS setting different DEPENDS, but commenting that all out makes it work, or adding:

DEPENDS lib : $(l) ;

in the if $(KEEPOBJS) makes it work. Either way.

The only way I know of to get building-a-library-directly-into-somewhere- other-than-the-local-directory to work correctly is to get your library target into a full-path before handing it off to the Library rule. Historically, when Jam was first being put together, that's how things were done -- we had a CONFIG file, part of which was a list of library-name symbols (e.g., LIBFOO), all of which had as their values a full-path name (e.g., $(BUILDDIR)/lib/libfoo.a), and library targets were specified as:

Library LIBFOO : foo.c bar.c ;

If you don't want to go that route, you could instead have a wrapper rule that does something like:

rule myLib { local l ; l = $(LIBDIR)$(SLASH)$(<:S=$(SUFLIB)) ; Library $(l) : $(>) ; }

This will get the object modules to be dependencies of the full-path library (e.g., /work/lib/libfoo.a(foo.o) -- the object modules will get built into the local source directory, the library will get built into $(LIBDIR), and the modules will only recompile as needed.

Alternatively, you could just let the library get built into the local directory then do an InstallLib on it. (Note: Since install isn't part of the dependencies on "all", if you want to both build and install, you have to run 'jam install').

Hope this helps, Diane

--- John Belmonte <jo@nanaon-sha.co.jp> wrote:

Has anyone run into the following? A known bug? I'm running on linux with recent binutils.

When LOCATE is set on a library target (or MakeLocate rule used), strange things start happening:

* The target is always remade even when it's current. Setting NOARSCAN option flag seems to fix this (at a performance cost)

* If the KEEPOBJS option flag is set, the library won't be created.

--John Belmonte

===== (hol@yahoo.com)