ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <>
Subject Re: basedir not set corretly in subant task...
Date Thu, 15 Jul 2004 14:20:14 GMT
Dominique Devienne wrote:
>>-----Original Message-----
>>From: Steve Loughran []

>>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.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message