On Wednesday 22 October 2003 15:04, Stefan Bodewig wrote:
> On 22 Oct 2003, Stefan Bodewig <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
