ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roger Vaughn <rogervau...@yahoo.com>
Subject Re: executing task for each file in file set
Date Mon, 18 Jun 2001 18:16:02 GMT
--- Stefan Bodewig <bodewig@apache.org> wrote:
> We will have to deal with this problem in the context of
> multi-threaded execution of tasks in a target anyway.  This probably
> means that bigger parts of the core need to be redesigned for
> multi-threading and that we document side-effects of some tasks
> properly (so people know when they are going to get themselves into
> trouble).

Sounds like parallelization is thorny (understandably).  Now I'm sorry I ever
mentioned it, even in jest.  I think it would be perfectly acceptable to say,
"apply-to-set will run for each member, but will not guarantee in what order,
and cannot yet support parallel execution."  Parallel execution is sexy, but
difficult.  As Peter mentions, depending on the machine and the tasks run, many
environments may not be able to support *effective* parallelization.  Because
of this, it effectively makes for non-portable scripts.

> More acceptable in a sense that it could be part of the core tasks
> while the others could not?  I'm not sure, really.  Let's say that
> following ant-user over the last weeks (ever since Tim has submitted
> his foreach task and Diane has started pointing people to it) has
> changed my mind quite a bit.  Usually I've asked people to explain
> what they are trying to do and searched for an alternative that
> wouldn't ask for these constructs - I still haven't seen an if or case
> example that has convinced me, while I've seen quite a few problems
> that could be solved by the foreach task (and I didn't know a better
> solution).

Well, I think I have found one.  If you have a better solution, I'm all ears.

I'm working on a project right now that includes small C++ extensions, and has
to run on Linux and Windows.  The complicating factor is that the project uses
*different* extensions, and thus different source code, for each platform.  The
Java code is common and makes adjustments for the OS at runtime.

The Java part is, of course, easy.  I'm running into trouble with the native
portions, though, where expanded conditional support would help out greatly.

I have a set of targets for each OS that look like this:

  <target name="winlib" depends="compile">
    <copy todir="${build.dll}">
      <fileset dir="${src.dll}"/>
    </copy>
    <exec failonerror="yes" 
          dir="${build.dll}" 
          executable="make" 
          os="Windows 2000"/>
  </target>

Notice that I use make to actually do the C++ compiles - this saves a lot of
headache in Ant.  However, this target does the copy task each time, regardless
of which OS I'm on.  I would like to be able to skip this step if it isn't
needed.  (Yes, it only *actually* copies the first time, but it takes up
unnecessary disk space, and does the file comparison on every build.)

One way around this is to eliminate the copy and build in place instead - but I
have gotten used to placing all build products in the "build" directory, and
like to keep the convention going, even when doing C++ work.

It's a small example, but I seem to keep bumping my head against it in various
parts of the script.  I would like to be able to detect which OS I'm running on
(easy) and react accordingly (not so easy without resorting to external
scripts).

The minimal feature to really do what I would like is an "os" attribute on a
target, similar to the one on "exec".  More powerful constructs, like being
able to test the values of properties, would also answer this particular
problem, but would have greater flexibility.

roger


__________________________________________________
Do You Yahoo!?
Spot the hottest trends in music, movies, and more.
http://buzz.yahoo.com/

Mime
View raw message