ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran" <>
Subject Re: Possible bug with <parallel>, <antcall> and depends
Date Thu, 02 May 2002 05:28:45 GMT

----- Original Message -----
From: "Chad Loder" <>
To: "Ant Developers List" <>
Sent: Wednesday, May 01, 2002 17:13
Subject: Re: Possible bug with <parallel>, <antcall> and depends

> Steve,
> Your response wasn't very helpful. :-) I already
> know that ant doesn't do parallel builds the way
> I expect. My real question is, "Should it?", and
> if not, why not?
> The documentation for <parallel> is not clear on
> this point.  Should this be considered a documentation
> clarity issue or an outright bug?

You seem to feel that the docs are inadequate. We welcome better
documentation :)

All <parallel> does is run tasks in parallel. That's it. no syncrhonisation,
no-coordination. It is not a parallel make a-la- clearmake. Now, as an owner
of a two-cpu system sometimes I'd like better intrinsic parallelisation, but
whenever I start to think that I remember to set build.compiler=jikes and my
problems go away

> Now, before I get flamed, I do understand how "depends"
> in ant is different than depends in GNU make. The ant
> documentation states:
>          "It should be noted, however, that Ant's depends
>          attribute only specifies the order in which targets
>          should be executed - it does not affect whether the
>          target that specifies the dependency(s) gets executed
>          if the dependent target(s) did not (need to) run."

statement (0), the core rule of ant dependencies

> However, right after this statement, the documentation also
> states:
>          "A target gets executed only once, even when more than
>          one target depends on it (see the previous example)."

call this statement (1)

> Then the documentation for AntCall states:
>          "When a target is invoked by antcall, all of its dependent
>          targets will also be called within the context of any new
>          parameters. For example. if the target "doSomethingElse"
>          depended on the target "init", then the antcall of
>          "doSomethingElse" will call "init" during the call."

CVS says I wrote that. And as far as I know, it is true :)

call this statement (2). When you call antcall you are calling <ant> on the
buildfile; a whole new context of execution.

> My point is, the "junit" target only gets executed once when
> multiple <antcall> tasks are specified.

yup. see statement (1)

actually, if your target was

    <target name="all-projects">
          <antcall target="httpclient"/>
          <antcall target="junit"/>
          <antcall target="log4j"/>
          <antcall target="xerces"/>

with no parallel, I would expect junut to get called as a dependency, as per
statement (2)

>  So far so good.
> However, when the <antcall> is inside <parallel>, this desirable
> behavior disappears. It sounds like a defect to me, and I'd
> be willing to submit a patch that fixes it, just as soon as
> someone tells me I'm right. :-)

what behavior do you desire? To not have dependencies executed when you call
<ant> or <antcall> (they are roughtly the same thing)? Wont happen. It is
not the intent of the task, and it breaks other builds.

To summarise:

ant doesnt do parallel builds the way you expect, and antcall re-execs all
the dependencies.

statement (3) from the "parallel" page :-

"Care must be taken when using multithreading to ensure the tasks within the
threads do not interact."

Which means: in parallel mode, anything goes. It isnt for parallel builds,
so much as running things like a server in its own for and your unit tests
at the same time.

Your problem is one of parallel child task execution...this could maybe be
done in its own JVM. Its too late to add a fork option to ant 1.5, but an
interesting exercise would be some task explicitly to run child builds, the
infamous <anton> task, which was always envisaged as taking a filesset of
target build files and running a target against them. In such a task, a
parallel mode might be very slick indeed.


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

View raw message