RE: [Q] How to avoid <antcall > with generic <script > target for s
ubprojects? | RE: [Q] How to avoid <antcall > with generic <script > target for s
ubprojects? 2003-03-28 - By Dominique Devienne
Andreas,
That's an interesting use case you are discribing. I never thought of it
myself, in part because I would have use another approach... Instead of
reusing the *same* build file for all the projects, which forces you to
explicitly set the basedir (using the 'dir' attribute), something I'm not
fond of, I would have created a hollow buid file for each sub-project that
(XML entity) includes a common.xml build file. That way, I can still build
each project individually (usually assuming it's dependencies have been
built before), and have them *share* a common build file content. Most
likely, your superproject build file contains stuff of no use to itself,
just for the benefit of the subprojects.
Given the approach described above, <subant> works like a charm. This is
actually how I've recently set things up to compile 30 shared libraries...
This approach also gives you a bit more flexibility, in that you can
slightly customize the build file for a given subproject. In my particular
use case, one shared lib requires code generation (.y/.l files), and I do
this in that project's build file only. You could argue that I could have
dealt with this in common.xml too, but it's actually simpler that way.
This is my take on it. I'm not saying your use case is invalid, I'm just
pointing out you can carry it out maybe more easily using the approach I
describe ;-) Good luck, --DD
-----Original Message-----
From: Andreas Ames [mailto:andreas.ames@(protected)]
Sent: Friday, March 28, 2003 7:16 AM
To: Ant Users List
Subject: Re: [Q] How to avoid <antcall> with generic <script> target for
subprojects?
Andreas Ames <andreas.ames@(protected)> writes:
> - Ant.execute: my current ant version (1.5.1 as packaged on Debian)
> just uses FileUtils.resolveFile to combine the basedir and the name
> of the antfile unconditionally. I would change that to only combine
> them if java.io.File.isAbsolute(antFile) returns false. Otherwise
> I'd leave antFile as it is.
Oops... I just recognized that FileUtils.resolveFile has the
undocumented feature, that it preserves the filename as is, if it is
absolute (but it doesn't use File.isAbsolute to determine this but
rather a method which seems specific to Unices and non-UNC Windows
filenames, but that would be enough for me)
Therefore Ant.execute should do what I want it to do if I specify an
absolute filename for the antfile attribute.
Thus my questions below should have been:
> - Would you consider such a 'feature' for SubAnt to be useful? Would
> the ant maintainers consider it to be useful for the Ant-task? If I
> understand FileUtils.resolveFile correctly, no existing antfiles
> should be broken by this change. But please note that I'm very new
> to ant.
If you, Dominique, would accept my 'feature', no patch against the
Ant-task would be needed. Would the ant maintainers accept the
described behaviour of the antfile attribute of <ant> as officially
suported?
> - Should I send a patch to this list or should I use the bugtracking
> system?
>
> - Against which ant version should I create a patch? Please note that
> I have no access to cvs (firewall issue).
Although I can't access cvs I could make a patch against the HEAD
revision of SubAnt.java if you prefer so (thanks to viewcvs).
TIA and sorry for following up myself,
andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@(protected)
For additional commands, e-mail: user-help@(protected)
|
|
 |
