Ok, I think I will try to go back to the drawing board and try to provide my simple definition of <local> as I originally proposed. I guess I did not look close enough your implementation.
>From your example bellow I see that <local> does not define a proper nesting context (which I think is wrong). In my original proposal <local> extended <sequential> and as such the life of the <local> was restricted to that nesting. For what I see in your example <local> is not defined as a nesting task and that concerns me. As per the <attribute> of <macrodef>, I tend to agree with you that probably it is not a good idea to treat it as a <local> since its expansion should be just on the expansion of the macro itself. But I think the issue here is in <macrodef> and not in the definition of <local>. Finally, I would argue that the burden of using ThreadLocals or watever should be on <parallel> and not is some other task or the CORE as a whole. If you want to parallelize tasks that interfere with one another, it should be upto to parallel to allow for independent computations. This should be a completely separate issue from that of <local> it should be an enhancement request on <parallel>. So lets talk this over some more, Jose Alberto > -----Original Message----- > From: peter reilly [mailto:[EMAIL PROTECTED] > Sent: 22 October 2003 18:36 > To: Ant Developers List > Subject: Re: Vote: <local> for 1.6 > > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
