[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ant-dev
Subject:    conditional compilation
From:       William Uther <will+ant () cs ! cmu ! edu>
Date:       2000-02-24 2:11:22
[Download RAW message or body]

Hi,
  I'm trying to move a project from gmake to ant.  Pretty much everything
converts except for some stuff that uses loops.  I'd like to add a few
commands.  I'll write them, but I was looking for some feedback on design
before I started coding.  It would be nice if this was worked back into the
common code.  Here are my thoughts:

The <list ... /> command:

<list name="propName" includes="..." excludes="..." separator="..."/>

Puts the included files in a list separated by separator.  The list is
stored in property "propName".  This one should be fairly easy to make as
an ordinary task.  It could be used to simulate extdirs, build classpaths,
etc.

The <ForEach ... > command:

<ForEach variable="i" list="propName" separator="...">
	<task />
	<task />
</ForEach>

or

<ForEach variable="i" includes="..." excludes="...">
	<task />
	<task />
</ForEach>

These both loop over the tasks, creating and executing the tasks each time
through the loop.  Each time through the loop, the property named as the
variable takes on a new value: either the next value in the list, or the
next file.

This looks like it might be tricky to implement.  There are two problems
that I see.  Firstly, while you can have "deep-xml", the deep-xml cannot be
an arbitrary task.  (This could be changed.  Maybe we need to modify
processNestedProperties() in ProjectHelper so that it uses arbitrary tasks
if there is no appropriately named createXXX method (and then calls
addTask(task) with the created task so the execute method knows of the
task?)?)

Secondly, currently all tasks are created, then all are executed (create A,
set A, create B, set B, execute A, execute B).  This means that the input
to task B cannot depend upon the result of the execution of task A.  The
semantics I was envisioning are more of the (create A, set A, execute A,
create B, set B, execute B) form.  Here A is executed before B is set and
so B can depend upon A's action.

The <switch ... > command:

<switch name="prop">
	<case value="val">
		<task />
	</case>
	<case value="val">
		<task />
	</case>
	<default>
		<task />
	</default>
</switch>

This executes all tasks in the first case statement where the named
property, "prop", has a value that matches the value supplied in the case
statement, "val".  If no case matches, <default> is executed.

Thoughts, comments?

\x/ill              :-}

P.S.  What was the rationale behind the current "create all tasks, then
toposort, then execute" ordering?  It would seem that the toposort only
requires the target dependancy graph to be known, nothing else.  If you
were to delay the creation/setup of tasks until just before execution you
would get a much more normal semantics.

[prev in list] [next in list] [prev in thread] [next in thread]