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
a target critical target test depends=critical
b 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.
(1)---a
multi-import (2)---b
(3)---c---dSo 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 [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
------------------------------------------------------------------------------------------------------------------------------------------ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
