ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dominique Devienne <DDevie...@lgc.com>
Subject RE: [new tasks] presetdef and macrodef
Date Thu, 14 Aug 2003 14:23:17 GMT
After all the praises, I hope my post doesn't sound too negative. I also
think it's a great addition Peter, I just have a few reservations ;-)

See below... --DD

> -----Original Message-----
> From: peter reilly [mailto:peter.reilly@corvil.com]
> 
> 
> <presetdef> (formally known as extendtype)
>   this defines a new task or type based on a current ant task or type,
>   with attributes or elements preset.
> 
>   example useage:
>   <presetdef name="my.javac">
>        <javac debug="${debug}" deprecation="${deprecation}"/>
>   </presetdef>
> 
>   <my.javac> may now be used as a task in the same way as <javac>
>   but the attribute debug and deprecation will be preset.

I'll start by neat picking ;-) What <presetdef> does is binding a given
value to a task attribute. In the C++ world, the method to do that are call
bind, which is IMHO better that preset.

Also, this kind of static attribute-binding is useful indeed (I've actually
asked for it a few times), but is hardly a definition, and it's bad that it
forces you to rewrite the task name. I don't want to modify all my builds to
use <my.javac> just to take advantage of that feature.

Finally, <presetdef>, in term of functionality and not implementation, is
just a subset of <macrodef> in my opinion, and doesn't deserve Task status.

Much more useful IMO was be the ability to bind (or preset) values using
XPath expressions, to follow your example:

//javac/@debug = ${debug}
//javac/@deprecation = ${deprecation}

To just do it for an instance of Javac inside a particular target, do

//target[@name='compile']/javac/@debug = true

I've always been annoyed to having to explicitly declare a bunch of task
attributes taking properties when sensible default values just to be able to
maybe override them.

So in conclusion, I'm +1 to the ability to bind values to task/type
attributes, but without requiring task name changes, and possibly with
requiring a task. I'm -0 to <presetdef> as it is.

A middle ground would be to have something like this, closer to your current
design:

  <bind-attributes>
    <delete quiet="true" />
    <javac debug="${debug}" deprecation="${deprecation}" />
    <exec failonerror="true" />
  </bind-attributes>

So it yields no task rename, work for any valid tasks, and is more explicit.


> <macrodef>
>   this defines a new task in the same way as <scriptdef> except it
>   uses a <sequential> as a defintion of the task. The <macrodef>
>   task has nested elements - param and element to allow the
>   user to specify attributes and elements of the new task. These
>   get substituted into the <sequential> when the new task is
>   run.
> 
>  example: (from a current project)
>      <macrodef name="call-cc">
>         <param name="target"/>
>         <param name="link"/>
>         <param name="target.dir"/>
>         <element name="cc-elements"/>
>         <sequential>
>             <mkdir dir="${obj.dir}/${target}"/>
>             <mkdir dir="${target.dir}"/>
>             <cc link="${link}" objdir="${obj.dir}/${target}"
>                 outfile="${target.dir}/${target}">
>                 <compiler refid="compiler.options"/>
>                 <cc-elements/>
>             </cc>
>         </sequential>
>     </macrodef>
> 
>     <macrodef name="compile-exec">
>         <param name="program"/>
>         <element name="cc-files"/>
>         <sequential>
>             <call-cc target="${program}" link="executable"
>                      target.dir="${build.bin.dir}">
>                 <cc-elements>
>                     <includepath location="${gen.dir}"/>
>                     <includepath location="test"/>
>                     <cc-files/>
>                     <linker refid="linker-libs"/>
>                 </cc-elements>
>             </call-cc>
>         </sequential>
>     </macrodef>
> 
>      <compile-exec program="unittests">
>             <cc-files>
>                 <fileset dir="test/unittest" includes = "**/*.cpp"/>
>                 <fileset dir="${gen.dir}" includes = "*.cpp"/>
>             </cc-files>
>       </compile-exec>

<macrodef> I have much less problem with, but I concur with others that
overloading the behavior of ${name} is not good. This will be confusing to
me and other users that property expansion will not happen as usual at
definition time, but later on. I think we need another syntax for the macro
param/attributes, and keep the ${} working as usual.

I propose to use either:
* the XSL syntax (@name)
* or a Javadoc-like syntax {@param name}

Another advantage of the second form is that one would not need to
pre-declare the macro params (making it scripting-language-like), but on the
other hand, pre-declaring makes it more explicitly when reading the macro
what parameters it takes. If we force pre-declaration, we can then fail on
dereference to non-declared macro-param.

Should param be renamed attribute? <macrodef>, from the build writer point
of view, creates a new tasks, and we always speak of attributes and nested
elements, not params and nesting elements.

I'm -1 to <macrodef> if it keep the ${...} expansion form for
params/attributes.

I'm +1 to <macrodef> using nested <attribute>s and <element>s, with (@name)
expansion.

> 
> Will I place these tasks in ant or ant-contrib ?

I use both, so I don't really mind ;-)

Thanks Peter, --DD

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


Mime
View raw message