Return-Path: 
 <dev-return-49845-apmail-ant-dev-archive=ant.apache.org@ant.apache.org>
Delivered-To: apmail-ant-dev-archive@ant.apache.org
Received: (qmail 97862 invoked by uid 500); 22 Aug 2003 12:59:59 -0000
Mailing-List: contact dev-help@ant.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:dev-unsubscribe@ant.apache.org>
List-Subscribe: <mailto:dev-subscribe@ant.apache.org>
List-Help: <mailto:dev-help@ant.apache.org>
List-Post: <mailto:dev@ant.apache.org>
List-Id: "Ant Developers List" <dev.ant.apache.org>
Reply-To: "Ant Developers List" <dev@ant.apache.org>
Delivered-To: mailing list dev@ant.apache.org
Received: (qmail 97813 invoked from network); 22 Aug 2003 12:59:58 -0000
Received: from unknown (HELO london.cellectivity.com) (212.18.242.163)
  by daedalus.apache.org with SMTP; 22 Aug 2003 12:59:58 -0000
Content-Class: urn:content-classes:message
Subject: RE: [new tasks] presetdef and macrodef
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 22 Aug 2003 13:58:22 +0100
x-mimeole: Produced By Microsoft Exchange V6.0.5762.3
Message-ID: <747F247264ECE34CA60E323FEF0CCC0C0F512F@london.cellectivity.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [new tasks] presetdef and macrodef
thread-index: AcNoCjKJL+DYGlx6QeGQfzVY03pTvAAnSZ0A
From: "Jose Alberto Fernandez" <jalberto@cellectivity.com>
To: "Ant Developers List" <dev@ant.apache.org>
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

> From: Gus Heck [mailto:gus-antdev@cognition.olin.edu]=20
>=20
> I'm not sure I buy your 3 things argument. In my mind there=20
> are 2 things=20
> in what is previously proposed...
>=20
> properties and parameters
>=20

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

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=3D"subcall">
        <param name=3D"xyz" value=3D"false"/>
      </antcall>

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

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=20
> defined macros with the same name and then one called the=20
> other. Granted=20
> this might be an xml namespaces thing, but the more parts of ant that=20
> require namespaces the steeper the learning curve for new users.
>=20

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