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 Fri, 22 Aug 2003 12:58:22 GMT
> From: Gus Heck [mailto:gus-antdev@cognition.olin.edu] 
> 
> I'm not sure I buy your 3 things argument. In my mind there 
> are 2 things 
> in what is previously proposed...
> 
> properties and parameters
> 

The question is when expantions happen. We are here in the MACRO
world, and in that world there are ussually those three things.

> Templates appear to be something new, though I don't think I 
> like them 
> (see below)
> 
> >  (1) --> ${xyz}
> >  (2) --> ${macroattr:xyz}
> >  (3) --> ${macrotemplate:xyz}
> >

Well, as I said I use those terms above just as examples, I am not
hookup in words, 
I was just looking for some identifier to describe them. Still the
concepts
I am expressing are very clasical ones, these are not things out of the
blue.

> >So for a definition like:
> >
> >  <property name="xyz" value="true"/>
> >
> Now ${xyz}" is true forevermore because properties are immutable
> 
> >  <macrodef name="abc">
> >    <attribute name="pqr"/>
> >    <sequential>
> >      <javac debug="${xyz}" ... />
> >
> This line ${xyz} should get replaced
> 
> >      <javac debug="${macroattr:pqr}" ... />
> >      <javac debug="${macrotemplate:xyz}" ... />
> >    </sequential>
> >  </macrodef>
> >  
> >
> I'm not sure how you get a second level of expansion, or if 
> it is desireable
> 
> >After this definition the macro that is actually expanded will look 
> >something like:
> >
> >    <attribute name="pqr"/>
> >    <sequential>
> >      <javac debug="true" ... />
> >      <javac debug="${macroattr:pqr}" ... />
> >      <javac debug="${xyz}" ... />
> >    </sequential>
> >
> >which will be further expanded in a call frangment, maybe inside an 
> ><ant> call:
> >
> >  <property name="xyz" value="false"/>
> >  <abc pqr="true"/>
> >  <abc pqr="false"/>
> >
> I'm not sure this makes sense (to me at least).... if it is 
> part of an 
> ant call, then the macrodef should be in the build file used in the 
> antfile atribute...  in which case your first javac might 
> also come out 
> with debug=false (assuming inheritall=false, and the property 
> definition 
> was before the macro definition) or debug="${xyz}" (unexpanded, and 
> causing the build to fail because it wasn't defined yet, if 
> the property 
> isn't before the macro definition, as you have shown). If the 
> task does 
> property replacement at invocation time, then you still 
> should get debug="false" for your first javac since the 
> property won't have been 
> expanded yet.
> 

Even when using <antcall/> the call may not redefine the macro
nor any other <taskdef/> in the buildfile. This may happen if the
definitions
are inside a target which is not evaluated as part of the antcall
target.

So it is completely possible to have the situation above. Furthermore,
the <antcall/> can be as follows:

	<antcall target="subcall">
        <param name="xyz" value="false"/>
      </antcall>

> If macro definitions are available to sub builds, then your 3rd case 
> might occur, but I don't think it would be good to allow macros to be 
> called across build file boundaries. builds would be almost 
> unintelligible without tracking down the macros from other files.
> 

This is all regular kosher ANT stuff, up to this day, <taskdef/>s get
inherited, they do not need to be redeclared for the task to be
available
during the <antcall/>. Are you proposing that we have a different,
special case,
semantics for <macrodef>?

> It would also bring up yet another scoping issue for 2 files that 
> defined macros with the same name and then one called the 
> other. Granted 
> this might be an xml namespaces thing, but the more parts of ant that 
> require namespaces the steeper the learning curve for new users.
> 

We already have a solution for the case of <taskdef> I would just like
the behavior on both cases to be the same, so to reduce the leaarning
curve.

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