-----Original Message----- From: Steve Loughran [mailto:[EMAIL PROTECTED]
In that case I have been using <ant> wrongly, forever.
Yep! Here's the corresponding manual section:
point taken. but it used to work :)
I always use the "dir" setting as it 100% guarantees that the dir is set up to that of the dest, which is how I usually work. And when you call <ant> in a sub project, using dir, it again sets up the basedir to be that of the destination.
Yeah, because you were basically always overriding the sub-builds basedir, but at the same time providing the same value. When you add subant in the mix, then this scheme breaks, because the mechanism to override the basedir is too strong (using a user-defined property). The sub-project, which sets the basedir itself, can't override the value, and SubAnt which does nothing itself with the basedir, appears to override the value, unlike stated in the documentation.
Exactly. It is the fact that basedir gets uprated to a user-def property that is the troublespot. It never showed up before because I was always recreating a new basedir of the same level.
We do not get that same chaining semantics with ant -> subant.
SubAnt internally relies an Ant to delegate to the subbuild, but never sets dir attribute (omitted in the table ablove), so it's the inheritAll attribute which decide for SubAnt whether to override the basedir or not, and in <subant>, unlike <ant>, it defaults to false.
What I take all this means is that if you chain (ant or subant) with subant, and override the basedir in the first ant or subant (but providing a dir or inheritAll=true in <ant>, or just inheritAll=true in <subant>), then you're messing up the second level (or third level, etc...) subant.
Thus I come back to my question about why basedir override was implemented in the first place. I didn't get an answer I liked so far. Maybe it's because I always design my build/subbuilds in such a way that any basedir override would break them, or said differently, that the build behaves the same way when called directly, or called from a parent/master build.
It is a mess. A mess that goes back a long, long way. I remember being confused before by the
inheritall behaviour screwing up basedirs, which is probably why I adopted the dir= pattern; set the build file that way and you isolate yourself from any side effects of changing the inheritAll flag.
I am not happy with the way the current combination of ant/subant works. I can work around it, but only if I control how the upper level build file is invoking my build files, which is hard to do. And to justify. And to use at all if InheritAll=true
Here are some things we could do
1. nothing. Leave things painfully inconsistent.
2. downrate basedir in <ant> to a normal property. What would this break?
3. have an attribute in subant that lets you force the basedir of the target build file.
steve
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
