ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <bode...@apache.org>
Subject Re: <available> task
Date Tue, 24 Apr 2001 14:27:24 GMT
Diane Holt <holtdl@yahoo.com> wrote:

> --- Stefan Bodewig <bodewig@apache.org> wrote:
>> Diane Holt <holtdl@yahoo.com> wrote:
>> 
>> > Is there a reason why the <available> task couldn't be changed to
>> > work at either the project-level or the target-level, the way
>> > <property> can?
>> 
>> What's special about <available> to make this change?
> 
> What's special about <property>?

Touché. 8-)

> I think any task whose purpose is just to set something probably
> should be available at the project-level (<filter> and <tstamp> are
> the only other ones I can think of) -- or none of them should
> be.

<uptodate> as well.

Allow everything that changes something internal to be placed outside
of targets and force everything that changes something external into
targets?

Sometimes this is difficult to decide, which category does <record>
belong to? Where do we put <script>?  I'm more leaning towards an all
or none approach.

That <property> and <taskdef> may be placed outside of targets can be
explained (like everything else) with "historical reasons".  I think
<property> really was not a task in James' first designs.

> For the future, it could be one way to determine scope, rather than
> going with an attribute to specify that.

Well, we'd need to define which scopes we want before we make a
decision on this.  Do we have file-scope and project-scope, do we have
an even more hierarchical view of the world (scope is this file and
all invoked subbuilds but not the parent build)?

Even if we end up with a total of two scopes, I think I'd still prefer
something explicit like an attribute - or even two different elements.

>> As soon as importing stuff from other build files or even
>> inter-build-file dependencies would come into the mix, we'd really
>> put ourselves into trouble.
> 
> What sort of trouble?

If a target in build file A depends upon a target in build file B, are
the tasks living outside of any targets in B going to be executed?
Which tasks living outside of targets do we execute first, A's or B's?

I realize we already have this problem with properties and taskdefs
(and Conor already addressed this with his initial -1 on the
inter-file dependency request).  If we find a solution for the
property problem, it probably also applies to other tasks as well.

So, you've put me back into an "undecided" state - it probably depends
on further discussion and implementation details for Ant2.  

I'd hesitate to change Ant 1.x semantics now, given that it might
change again in Ant2.

Stefan

Mime
View raw message