ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <jalbe...@cellectivity.com>
Subject RE: [new tasks] presetdef and macrodef
Date Thu, 14 Aug 2003 17:50:55 GMT
I think this is fantastic work.
As per Dominique's reservations, here are some observations that may
make things easier.

> From: Dominique Devienne [mailto:DDevienne@lgc.com]
> 
> > 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.
> 
> 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.
> 

One thing you could do here is redefine <javac> itself
by doing something like:

   <taskdef name="orig.javac" classname="org.ant.....Javac"/>
   <presetdef name="javac">
	<orig.javac debug="${debug}" deprecation="${deprecation}"/>
   </presetdef>

which would realize your desired effect. This could be done internally
by <presetdef/> when for example no name attribute is given.

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

I disagree here, IIUC, <macrodef>'s templates must have ALL the
content and parameters of the tasks inside, while <presetdef/>
only sites some sort of default values.

It would be interesting to know what would happen if I write:

   <my.javac debug="true"> ... </my.javac>

would it use the value given in <presetdef> or that given in the actual task?
If the later, it means that the values given in <presetdef> would be
default values for the task, which sounds much better. 
Maybe we could rename it <defaultdef/>. :-)

> 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
> 

This sounds like global file transformations, since you are applying
the xpath all over, seems like something for a ProjectHelper like to do.

> 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.
> 

More in the middle is something like the notation I proposed above, 
which allows the user to decide whether he wants diferent flavours
(different names) or just globally apply the change.

> 
> > <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 really do not see what is so confusing, but +0 about it. <param/> defines
a "local" property which is expanded at call time. I have always wanted

Jose Alberto
 

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


Mime
View raw message