On Tue, Apr 24, 2001 at 04:19:45PM -0400, Glenn McAllister wrote:
> <target name="do_many_things" depends="foo,bar,blat">
> <parallel>
> <javac ... /> <!-- compile source -->
> <copy todir="${deploy.dir}" ... /> <!-- copy properties files into the
> class
> tree -->
> </parallel>
> </target>
NB: I've modified one line in the above quote, since I have
things to say about dependencies; the line originally read:
> <target name="do_many_things" depends="...">
You're thinking in terms of telling ant when two things can be
done in parallel; it's better to think in terms of telling it
when they *can't* be, and letting it default to parallel unless
told otherwise. Like this:
<target name="build" depends="compile,copy_properties"/>
<target name="compile" depends="foo,blat">
<javac ... /> <!-- compile source -->
</target>
<target name="copy_properties" depends="bar">
<copy todir="${deploy.dir}" ... /> <!-- copy properties files into the
class -->
</target>
Looks familiar, no? :-) Since neither "compile" nor
"copy_properties" depends on the other, ant can do them in
parallel. *No* additional syntax is required to say that.
> What if one parallel target depends on another?
Then they're not parallel, by definition. Or rather, parallelism
isn't an attribute of a target (or a task) in the first place;
it's an attribute of the relationship between two of them.
> How do we resolve order?
The "depends" clauses.
Isn't that what "declarativeness" is all about -- let me just
tell you *what* needs to be done, not how (or in this case, when)
to do it?
Note also that with parallel tasks, the "foo,bar,blat" that
"do_many_things" depends on is the union of the dependencies for
both the <javac> and <copy> tasks (and potentially many more).
With parallel targets, each such dependency is explicitly
associated with the task that actually depends on it. You don't
need a <parallel> kludge to tell ant that the two tasks have no
mutual dependencies, because you've already told it in the
targets' "depends" attributes (by not naming any).
Reentrancy is a separate issue. If only one copy of a given task
can be running at once (eg. because they share output files, like
old-fashioned yacc implementations in the C world), ant has to
know that. But it's just another datum used by the scheduler --
probably defined statically in the task's implementing class.
> The concensus seems to be that the complexity involved would override the
> benefit.
The complexity of implementation may well do so; I don't know the
code well enough to say (though it's been done in at least a
few make's).
Complexity of *use*, on the other hand ... well, adding a
<parallel> keyword to express what the syntax can already say
doesn't strike me as making things simpler...
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont. [EMAIL PROTECTED]
| | /
Those who don't understand UNIX are condemned to reinvent it, poorly.
- Henry Spencer
