Christian> how do I specify inter directory dependencies?

I would like to see some discussion on this topic. The way to specify interdirectory dependencies depends on the way you handle grist. It comes down to policy issues -- I suspect different and incompatible policies may be useful in different circumstances.

When it's possible to have unique file names across all your directories, then there is no need to fiddle with grist at all. The suggestion that Phil made to solve Christian's problem looks basically right to me, though I haven't run a test case. Note that to build the app, "jam" will have to be run from the top- level directory.

I have build trees for four seperate programs, and a library. Some of the programs require the executables of the other programs in order to build, and all of them require the library. The rule I tried to follow was that typing jam within any program directory should build just that program.

top/thelib/thelib.a /l1.c /l2.c /l3.c /app1 /lib/thelib.a -- a copy /a1.c /a2.c /a3.c /app1.exe /app2 /lib/thelib.a -- a copy /bin/app1.exe -- a copy /a1.c /a2.c /a3.c /app2.exe

I faced two problems: 1) When jam runs, it looks at the Jamrules file at the top of my tree, but only the jamfiles at or below the point of invocation. I couldn't figure out a nice way to reference files outside of the subtree. 2) Some of my programs have different source files with the same name, so I was going to have to use grist to differentiate them.

Solution for (1) I made a virtue of a necessity: when you build any program, the jamfiles in that subtree treat the libraries and executables supplied from other subtrees as source -- they expect the files to be already built and copied into the subtree, and there are no local rules for building or copying them. This makes local program builds fast since jam doesn't have to parse the entire jamfile tree.

When jam is run from the top level, the subtree jamfiles collect the information about which subtrees use files from other subtrees. I wrote a "jam install" target at the top level which copies the files that each subtree uses from other subtrees into that subtree's local area. You might think that this takes a lot of space, but so far it's not an issue, and I might use hard links for the copy if it's a problem.

Solution for (2) The copies generated by solution 1 cause Jam to see multiple files with the same names, and would require a solution to problem (2) even if I could keep all the source file names in my different programs unique. So I have to add grist to at least some of these file names. For consistency, I add grist to every file I reference (the grist I add is the standard grist for the file's directory).

The standard rules (Main, Library) take care of adding grist to the source file names referenced, but the built object file does not have grist added to its name. Because these files are the ones aliased by the copies above (and for other reasons too), I built my own Main and Library rules which add the appropriate grist.

This policy of adding grist to built object names appears to be at odds with the way the original Jambase was conceived, and requires me to use different rules, which is unfortunate since I will no longer track bugfixes to the Jambase on updates. Yet my policy appears to be an unavoidable consequence of trying to make subtree builds work. This brings me back to my version of Christian's question: Has anyone had experience with invoking Jam below the top level to do subtree builds using the default rules? Does it work, what restrictions on filenames are there, and what sorts of build targets can be invoked at which part of the tree?

- -Iain McClatchie ia...@mcclatchie.com