----- Original Message -----
From: "Scott Stirling" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, January 10, 2001 18:06
Subject: RE: documentation (and a RESUBMIT)
> Nice doc, dude. I read this. It's well written, clear. Bit of a tease
> with the mention of XSL to gen build files, but OK.
I dont use XSL, so cant cover how it can be used. Someone else needs to
cover that.
> It'd make a nice
> overview doc for practical applications and usage patterns in medium to
> large projects.
That is its intent.
Actually, since writing it I've had a weakness in the (very common) style of
having a heirarchy of autonomous projects, each with their own lib\ and
build\ directories.
If you want the output of all the builds to end up in one place, and the
libraries from one project acting as inputs to another, it makes more sense
to have single build/ and lib/ directories at the top of the heirarchy. But
if the sub project files are intended to be standalone they can't tell where
the top of the heirarchy is.
The solution pointed out to me is to have a standard practise of defining a
base directory in a property
<property name="dir.base" location="." />
then define the subdirs relative to it
<property name="dir.build" location="{dir.base}/build" />
<property name="dir.lib" location="{dir.base}/lib" />
If a parent project wants to move the lib and build directories upstream,
then it just makes its own declaration of the base directory and
'immutability propagation' for want of a better name ensures that the sub
projects pick up the change.
Does that seem a) workable and b) reasonable? If so I will submit it as a
diff to my own document.
-steve