ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chad Loder <clo...@acm.org>
Subject Re: Possible bug with <parallel>, <antcall> and depends
Date Thu, 02 May 2002 07:08:30 GMT
At Wednesday 5/1/2002 10:28 PM -0700, you wrote:
> > 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 :)

I'd be happy to contribute documentation as soon as I get
a handle on what the intended and actual behavior really *IS*. :)
Your email has helped clear this up quite a bit, so
thank you.

>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

The choice of compiler has no bearing on what I'm saying. I have
separate, completely independent subprojects (with their own,
independent source directories) which need building.  I would
like their mutual dependencies to get built at most one time,
as per statement (1) from the ant docs:

> >     "A target gets executed only once, even when more than
> >     one target depends on it (see the previous example)."

I want this to happen even when they are built in parallel.

Currently, if I don't use <parallel>, the mutual dependencies
of all the <antcall>'s are executed at most once (the desired
and expected behavior).

If I DO use <parallel>, the mutual dependencies of all the
<antcall>'s are executed multiple times, which is undesired,
unexpected, and not clearly stated in the docs IMHO. Since
I don't have CVS commit access, if you want to add my example
to the docs and say "This example illustrates ant's <parallel>
behavior, which may be counter-intuitive to people coming
from make-centric build systems, in that mutual dependencies
are executed multiple times", please do.

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

If that's the explanation for why <parallel> <antcall>'s
cause mutual dependencies to be executed more than once,
then why should <parallel> make any difference?

> > 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"/>
>     </target>
>
>with no parallel, I would expect junut to get called as a dependency, as per
>statement (2)

It does get called -- only ONCE, as per statement (1). That's
the desired behavior.

>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.

No. The behavior I desire is for statement (1), "A target gets executed only
once, even when more than one target depends on it", to hold true when
tasks are <antcall>'d in <parallel>.  It currently holds true when tasks
are <antcall>'d serially, I simply want it to work the same way when they
are called in <parallel>. But see below.

>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.

OK. Maybe the docs should be corrected to state explicitly that <parallel>
is not intended for <parallel> builds, because statement (3) as it stands,
doesn't mean what it says...or it doesn't say what it means. :)

"Ensuring that tasks within threads do not interact" is not the same
as "Ensuring that tasks within threads do not share mutual
dependencies, even though the tasks themselves are independent."

>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.

That's much more complex than what I want. All I want is for a set of
independent tasks to be executed in parallel, while their mutual
dependencies (recursively) are executed at most once.

Actually, I can't imagine that <parallel> is widely found even to
be useful for building anything! In fact I just did a check
through the jakarta-ant, jakarta-commons, junit, and xerces build files
and found only one use of <parallel>, and this was to run unit tests.

I couldn't possibly replace our rather large build system (implemented
in GNU make) with ant until ant supports parallel builds. I'm a rather
handy Java programmer myself and I don't mind writing a taskdef for
"transitive closure" parallelism. However, I'm rapidly getting the
impression that this style of build is contrary to the spirit of
ant for some reason, and I'd obviously like whatever I design to be
acceptable to the ant maintainers. Any thoughts from you ant people
out there? Has work already been done in this area?

Thanks,
         c


--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


Mime
View raw message