> I am interested to know why is it desirable to have the parallel
> executor work on unmodified build XML files.
Because its easier to use.
Dont forget - this executor is not the default one.
Jan
-
To unsubscribe, e-mail: [EM
On Thu, 2007-12-20 at 13:45 +0100, Gilles Scokart wrote:
> > As I mentioned earlier the only road-block at the moment to a totally
> > transparent mechanism for
> > supporting parallel execution is the dubious implicit dependencies that the
> > documentation for the
> > "depends" attribute makes
> -Original Message-
> From: Robin Chaddock [mailto:[EMAIL PROTECTED]
> Sent: mercredi 19 décembre 2007 15:42
> To: Ant Users List
> Subject: Re: AW: extended parallelism
>
> The target "depends" attribute already gives all the information you need to
[EMAIL PROTECTED] wrote:
you'll get the following dependencies among the _tasks_:
taskb1: -none-
taskb2: taskb1
taskb3: taskb1
where is ? Just for annotating?
taskb1 : -none-
parallel: taskb1
and the execution of 'parallel' would be
taskb2: - none-
taskb3: t
> Sure, but you can regard the body of a target as having an
> implicit block.
yes
>
>
>
>
>
>
>
>
> you'll get the following dependencies among the _tasks_:
>
>
> taskb1: -none-
> taskb2: taskb1
> taskb3: taskb1
where is ? Just for annotating?
taskb1 : -none-
[EMAIL PROTECTED] wrote:
Usually tasks have to be processed sequentially.
Jan
Sure, but you can regard the body of a target as having an implicit
block.
e.g.
you'll get the following dependencies among the _tasks_:
taska1: -n
> sure. But if you would use and parallel execution
> of targets at the
> same time, you could end up in many more executing threads
> than the system can
> efficiently cope with (memory, CPU, I/O wise). One could try
> to break the target
> parallelism down to the task parallelism on the
>
[EMAIL PROTECTED] wrote:
Thinking a little bit more about the issue, I was wondering
whether it would be
a good idea to integrate the target-level parallelism (as
discussed here) and
the task-level parallelism (i.e.
task) into one beast, as such issues
like output handling and maximum number of
scripts in the wild that rely upon it :( )
- Original Message -
From: Chuck Holzwarth
To: Ant Users List
Sent: Wednesday, December 19, 2007 2:33 PM
Subject: Re: AW: extended parallelism
The problem with giving a command line option is that ant is effectively a
set of rul
> Thinking a little bit more about the issue, I was wondering
> whether it would be
> a good idea to integrate the target-level parallelism (as
> discussed here) and
> the task-level parallelism (i.e.
> task) into one beast, as such issues
> like output handling and maximum number of threads
PM
Subject: Re: AW: extended parallelism
The problem with giving a command line option is that ant is effectively a
set of rules. The rules form a tree and the dependencies give a list of targets
that are to be executed before the current target. There would have to be some
intelligence in the b
The problem with giving a command line option is that ant is effectively a set
of rules. The rules form a tree and the dependencies give a list of targets
that are to be executed before the current target. There would have to be some
intelligence in the build file that would show ant which tarte
Antform is available on sourceforge. I use it to provide a form for users to
select options during the compile or to get the username and password for the
CM system.
SVN login
This puts a form up for user input. The problem would be that if the parallel
tasking redirects out
> It may be better to stay away from a grammar that gives the
> rules and use something like:
>
>
>...
>
>
You could provide another executor ;)
In my approach I dont want the user to change the buildfile. Just set
the property on command line.
ant -Dant.executor.class=ParallelEx
> As I understand it, the order is respected under
> simple circumstances, but ultimately the dependency
> graph is calculated such that a dependency is executed
> however early it must be to ensure that every target's
> dependencies precede it.
That is what I thought.
The contract is only that
Chuck Holzwarth wrote:
Perhaps the facility that spawns the targets could manage the screen/buffer
output. This would mean that some facility would have to exist similar to
named pipes in Unix. This way, console output would be directed from the
buffer (or pipe) that had first output while other
Perhaps the facility that spawns the targets could manage the screen/buffer
output. This would mean that some facility would have to exist similar to named
pipes in Unix. This way, console output would be directed from the buffer (or
pipe) that had first output while other targets would be produ
Chuck Holzwarth wrote:
[...]
How do you propose to handle potential fatal/non fatal errors? If target a
exits due to an error, should there be an option to kill a or allow it to
complete (similar to failonerror="yes/no")? If both a and (b,c) must succeed
for d, should a be killed if b or c fails
It may be better to stay away from a grammar that gives the rules and use
something like:
...
How do you propose to handle potential fatal/non fatal errors? If target a
exits due to an error, should there be an option to kill a or allow it to
complete (similar to failonerror="yes/no
--- Klaus Malorny <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
>
> > Oh, have to have a look at that. If I change the
> semantic this has to be
> > made explicit ...
> > (It can be done because you have to specify the
> executor for your own
> > ...)
> >
> > "Ant tries to execute the t
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: mardi 18 décembre 2007 12:33
> To: user@ant.apache.org
> Subject: AW: AW: extended parallelism
>
> > >>
> > >> If such a dependency did exist, it should be incorporated in
> > >> the d
[EMAIL PROTECTED] wrote:
Oh, have to have a look at that. If I change the semantic this has to be
made explicit ...
(It can be done because you have to specify the executor for your own
...)
"Ant tries to execute the targets in the depends attribute in the order
they appear (from left to right)
dependencies is
fundamental to adding support for parallel target execution. (without adding
additional complication to the depends syntax)
- Original Message -
From: Klaus Malorny
To: Ant Users List
Sent: Tuesday, December 18, 2007 11:08 AM
Subject: Re: AW: extended paral
> >>
> >> If such a dependency did exist, it should be incorporated in
> >> the depends attribute of the 'b' & 'c' target declarations.
> >
> > Thats the meaning - unordered list.
> >
> >
> >> Assuming in the example above that targets b, c & d have no
> >> dependencies of their own, they sho
[EMAIL PROTECTED] wrote:
Isn't this the default behaviour anyway?
No - there is no multithreading by default.
That's why I write the ParallelExecutor.
If such a dependency did exist, it should be incorporated in
the depends attribute of the 'b' & 'c' target declarations.
Thats the meanin
> Isn't this the default behaviour anyway?
No - there is no multithreading by default.
That's why I write the ParallelExecutor.
>
> If such a dependency did exist, it should be incorporated in
> the depends attribute of the 'b' & 'c' target declarations.
Thats the meaning - unordered list.
need for additions to the syntax.
Fundamentally "depends" should be treated as an unordered set, not an ordered
list to do otherwise is making an unsound assumption upon the underlying Ant
implementation.
- Original Message -----
From: Klaus Malorny
To: Ant Users List
Se
PREREQUISITE_FAILED;
}
}
---8-<---8-<---8-<---8-<---8-<---8-<---8-<---8-<
> -Ursprüngliche Nachricht-
> Von: Klaus Malorny [mailto:[EMAIL PROTECTED]
> Gesendet: Dienstag, 18. Dezember 2007 10:10
> An: Ant Users Li
Hi,
with the increased availability of multi-core systems, I am wondering whether
there are ways to improve the capabilities of Ant to parallelize the build
process. While it is possible to execute tasks in parallel within a target, it
seems to not be simple to execute multiple targets in parall
29 matches
Mail list logo
