ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Vote: <local> for 1.6
Date Thu, 23 Oct 2003 05:55:34 GMT
I agree that <property> doesn't work well with <macro> and some other
use cases. 

I'm +1 on <local> if we can keep it separated from <property>, so the
behavior of <property> doesn't change. I think it may be a good idea to
even throw an exception if some name is used with both local and property.
I wouldn't mind even a <var> that is local + modifiable. 

I don't like the second example where local seems to be used to declare
filepath that is later defined as a property.

Another approach is to use namespaces for properties - IMO that's a cleaner
solution, but has the disadvantage that overloads <property> behavior.
( a local:foo property name will imply a local lifecycle, a att:foo could
be used for a modifiable property, etc ). I know this isn't very popular :-)


peter reilly wrote:

> On Wednesday 22 October 2003 15:04, Stefan Bodewig wrote:
>> On 22 Oct 2003, Stefan Bodewig <> wrote:
>> > I haven't made up my mind on the feature itself
>> OK, re-reading the description first, I don't like the
>> ,----
>> | The value part of <local> is optional, and  the local
>> | property may be set by a subsequent <property>, <property>
>> | will only set it if the value is not set.
>> `----
>> part.  This means that whenever I find a <property> task I'll have to
>> search all possible scopes for a <local> element and can't rely on it
>> being global.
>> What is the benefit of making <property> adhere to the scoping set up
>> by <local>?
> The point is that all tasks including <property> see the local
> properties as normal properties.
> It means that the macro attributes are now seen as normal
> properties by the tasks that are contained within the sequential
> nested element.
> The <local> makes a property of the same kind as the macro attribute.
> A common use case for this is when converting an antcall to a macro:
> I had a target that was used as an antcall target, it used a property
> "suite.pattern" to contain a regex what was used a number of times
> in the target and as an ant call was done to invoke the target, this
> was not seen outside the target. On conversion to a macrodef, the
> property "suite.pattern" is now a global property and the macrodef
> may fail unexpectly.
> With local the macro now looks like this:
>   <!--
>        macro to generate test suites registing
>        @param gen.dir  the dir to place the register_suites.h and .cpp
>        files @param unit.dir the dir that the unit_*.cpp files are located
>        -->
>   <macrodef name="gen-register-suites">
>     <attribute name="gen.dir"/>
>     <attribute name="unit.dir"/>
>     <sequential>
>       <local name="suite.pattern" value="^ *SUITE\(.*,\s*(.*)\s*\)"/>
>       <mkdir dir="${gen.dir}"/>
>        ...
>     </sequential>
>  </macrodef>
> Another common use case is use of a local to pass information from one
> task to another without messing up global properties or similar properties
> used in other targets (say in a complicated build with a number of imports
> and lots of targets).
>    <local name="filepath"/>
>    <pathconvert property="filepath" targetos="unix"
>                 refid="files.path"/>
>    <echo>the files in "files.path" are ${filepath}</echo>
> However I can see the problem of looking at a script and not knowing if
> the property is local or global.
> The last patch allowed [sub]ant[call] to inherit the local properties.
> I propose to change the local so that this inheriatance is removed and
> also that macro instances do not inherit the local properites - i.e.
> the local properties are staticlly scoped in the build script.
> So currently the following is the case:
>     <property name="p" value="global"/>
>     <macrodef name="inner">
>       <sequential>
>         <echo>p is ${p}</echo>
>       </sequential>
>     </macrodef>
>     <macrodef name="outer">
>       <attribute name="p"/>
>        <sequential>
>           <inner/>
>        </sequential>
>     </macrodef>
>     <outer p="from macro"/>
> Will generate "p is from macro" which is probally not expected as
> inner was not explicilty passed the property by outer and inner
> may be in another file or in an antlib.xml.
> Peter
>> I don't have any strong objections against the rest or the
>> implementation.
>> So +0.5 (which can be turned into a +0.9 by explaining why <property>
>> should care about scopes 8-).
>> Stefan
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message