8 messages in com.perforce.jammingDependencies on installed targets
FromSent OnAttachments
"Peter Faller BSW peter.faller@bsw.co.za17 Jun 1999 02:33 
Iain...@ix.netcom.com17 Jun 1999 19:11.html
Rand...@mdsi.bc.ca17 Jun 1999 19:57 
"Peter Faller BSW peter.faller@bsw.co.za18 Jun 1999 00:55 
Igor...@fi.uib.no18 Jun 1999 02:13 
Dian...@whistle.com21 Jun 1999 13:31 
"Peter Faller BSW peter.faller@bsw.co.za25 Jun 1999 01:44 
Dian...@whistle.com28 Jun 1999 14:03 
Subject:Dependencies on installed targets
From:Dian...@whistle.com (Dian@whistle.com)
Date:06/21/1999 01:31:55 PM
List:com.perforce.jamming

Hi Peter,

I gave what you're looking to do some thought over the weekend (while I was rototilling my backyard :), and I came up with a way that I think will give you what you're looking for.

Here's what you'd have:

1. You run your full build in your work area, and once everything's all built and you're ready to sign off on it,

2. Put the source and build product into some "static" (i.e., read-only) place, which is accessible to everyone (e.g., they can mount it onto their machine), then

3. Have your development work-areas be "sparse" trees, which contain the directories, the Jamfiles, and only those source-files that are actually being worked on, then

4. Have Jam look for source files, first in the work-area directory(s), and if the file(s) for the target exists, and are newer than either the local target file (if one exists) or the target file in the "static" tree, then Jam will build the target into the local work-area source directory,

else, look for the source file(s) in the "static" tree (where the target for it also is, and thereby not build it, since the target in that tree is up-to-date with the source in that tree).

That's it in a nutshell. (Note that you don't move targets into some place using the Install* rules -- you still can do that, if you need to provide people with stuff for some purpose other than building, but for building purposes, you don't want to do that [not just for this way, but for any way].)

Here's some sample output, under various conditions, to give you a better idea of how it works:

diane% cd $TOP/src diane% ls Jamfile foo/ libb/ bar/ liba/ libd/

(Initially, my development work-area contains only the directories and the Jamfiles, and no source files at all.)

diane% jam ...found 27 target(s)...

(Note that nothing gets built, because at this point everything is up-to-date, since all the targets are found in the "static" tree, along with the source that built them.)

diane% cd bar diane% <some-source-getting-tool> bar.h diane% vi bar.h diane% cd .. #back up a level, since it's more illustrative diane% jam -d2 ...found 21 target(s)... ...updating 2 target(s)... Cc /tmp/peter/dev/src/bar/bar.o cc -c -O -I/tmp/peter/dev/src/bar -I/tmp/peter/static/src/bar -o / tmp/peter/dev/src/bar/bar.o /tmp/peter/static/src/bar/bar.c Link /tmp/peter/dev/src/bar/bar cc -o /tmp/peter/dev/src/bar/bar /tmp/peter/dev/src/bar/bar.o / tmp/peter/static/src/libd/libd.a Chmod /tmp/peter/dev/src/bar/bar chmod 711 /tmp/peter/dev/src/bar/bar ...updated 2 target(s)...

(Note that only target "bar" is getting rebuilt, and it's using the source file (bar.c) and the libraries provided in the "static" tree, but is picking up bar.h locally, which is newer, so it's building a local bar.o, which it uses to link a local bar.)

diane% ls bar Jamfile bar* bar.h bar.o diane% cd liba diane% <some-source-getting-tool> a.c diane% vi a.c diane% jam ...found 11 target(s)... ...updating 2 target(s)... Cc a.o Archive /tmp/peter/dev/src/liba/liba.a ar: creating archive /tmp/peter/dev/src/liba/liba.a Ranlib /tmp/peter/dev/src/liba/liba.a ...updated 2 target(s)...

(NOTE: If you modify a library module, and the library's not been built locally yet, you MUST build it before running 'jam' anywhere else, so that Jam can find the local library and pick that up instead of the "static" one [assuming you -want- Jam to pick up your change -- if not, wait till you do]. Once the library's been built locally once, you don't need to build it first if you change its source again -- running 'jam' anywhere that includes the library in its scope will rebuild it.)

diane% ls Jamfile a.c liba.a diane% cd .. #Now back up a level to relink any exes as needed diane% jam -d2 ...found 21 target(s)... ...updating 1 target(s)... Link foo cc -o /tmp/peter/dev/src/foo/foo /tmp/peter/static/src/foo/foo.o /tmp/peter/dev/src/liba/liba.a /tmp/peter/static/src/libb/libb.a /tmp/peter/st atic/src/libd/libd.a Chmod foo chmod 711 /tmp/peter/dev/src/foo/foo ...updated 1 target(s)...

(Note that foo.o is picked up from the static tree, since I've not modified any of target foo's source -- only one of the libraries it links against has changed, so Jam is picking that up locally and getting everything else from the static tree. [foo is the only exe that links with liba; bar uses libd.])

diane% ls foo Jamfile foo*

(So here's what my development work-area looks like after working for awhile.) diane% pwd /tmp/peter/dev/src diane% ls -R Jamfile foo/ libb/ bar/ liba/ libd/

./bar: Jamfile bar* bar.h bar.o

./foo: Jamfile foo*

./liba: Jamfile a.c liba.a

./libb: Jamfile

./libd: Jamfile

(Okay, time to go garden some more... :)

If this is what you were looking to do, let me know, and I'll send the rules and Jambase tweaks and all of that that you need to do it. (If not, oh well, guess I misunderstood what you were looking to do, so you can try explaining it again if you want.)

(P.S. It is kind of a perversion of the way Jam should work -- but hey, what's life without a little perversion? :)

Diane (dia@whistle.com