----- Original Message -----
From: "Greg 'Cosmo' Haun" <[EMAIL PROTECTED]>
> Here is an element of style, and also a disagreement RE: your example
> element.
>
> - Use description attributes to comment your build file.
>
> All tasks have a description attribute, as do targets and projects. By
> using them, you can build documentation for your build process using
> something like this XSL transform:
Thanks for the great tip and XSLT file to go along with it!
> As for your example of building paths up from previously defined
properties,
> I used to use that strategy but found with complex builds it took too many
> steps to figure out exactly what path corresponds to a property. With
> built-up properties, you have to look at the property definition of the
> property in question, then the definitions of the properties used
appearing
> in that defintion, and so on and so on. I now prefer to define the
> properties directly, so that when I'm looking at a property I simply do a
> text search for the property name and since it's at the top of my build
> file, its full definition shows up instantly. If I need to change a base
> directory, I simply use global search and replace. It doesn't sound as
> elegant, but I breath a sigh of relief when I find a property defined
> directly.
This is not so much an issue now that there is an <echoproperties/> task.
You could put that in a "debug" target that you call when you want to see
how things are set (assuming things are set outside targets or in an "init"
target that "debug" depends on) and you can then see how things are
configured and work off that.
I agree that in a complex build it can be an overwhelming amount of
indirection going on, but I think the benefits of that indirection outweigh
the backtracking it takes to unwind it and figure out how things are set.
Erik
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
