ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: ant 1.5.4 : Import
Date Wed, 30 Jul 2003 08:45:48 GMT

Conor MacNeill wrote, On 30/07/2003 0.10:

> On Tue, 29 Jul 2003 05:52 pm, Nicola Ken Barozzi wrote:
>>Personally, I don't see the real need for it, as the same can be done
>>with correctly-written @importable files. In the specific, init values
>>should be included rather than imported.
>>Can you point me to some relevant use-cases?
> Ok, attached is a small test case which shows the failings of <import> when 
> there are target name collisions. In this case the dependency of "test" to 
> "critical" in b.xml is incorrectly replaced with a depenency on the 
> "critical" target in a.xml. 

Woah, this is a really nice test!

I strongly encourage all that are interested in <import> to unzip it and 
run it, it's very insightful.

> Target renaming doesn't help here. Having everything in a single project 
> namespace remains a problem. I'd say the number of target name collisions 
> between imported build files is going to be high because of the tendency to 
> choose target names from a small pool of common names.

Houston, I think we have a potential problem here. You are right.

I have never encountered this because I always write small imported 
files with not many targets, and each library has unique-name targets.

The issue stems from the fact that overriding works also *between* 
imported files. So what happens is that an imported file silently is 
able to override a target in another imported file without me knowing 
it, and I agree that it's nasty.

Let's see what the behaviour should be here.

multi-import(import a,b)
   target test depends=a.test, b.test

   target critical
   target test depends=critical

   target critical
   target test depends=critical

Here "critical" means a.critical to a and b.critical to b, but since 
they reference a generic "critical", they get the only one that remains 
after being redefined. The problem is that I did not redefine it in the 
main buildfile!

OTOMH this could be solved by rewriting all dependencies that are not in 
the import line.

  multi-import (2)---b

So rewriting should block collisions between (1), (2), (3), but enable 
them inside those lines.

What had been proposed is using "fully qualified" names in targets that 
I do not want to be redefined, which could be ok conceptually, but the 
issue is that the implications of sideways crosstalk between import 
lines are not transparent to the user, and thus should be avoided.

What I need is to be able to import build dependencies along with the 
targets. Probably the above solution should fix this error and make it 
work, no?

Other suggestions on how to do it while keeping the functionality that 
import now gives?

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

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

View raw message