DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=30459>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=30459 Support for Functions Summary: Support for Functions Product: Ant Version: 1.1 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Core AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Not sure if I am trying to bring in Generic Language features in ant. Just passing on my thoughts to forum to decide if this makes sense. This idea came to me while I was trying to compile huge number of c files, whose compilation is very similar except for few arguments. For compiling the files I used the following code to compile the files <exec executable="${cc}" dir="${storage.src}/" failonerror="true"> <arg line="${cc.arg.line.prefix} xyz.c -o ${cc.obj.dir}/../xyz.o"/> </exec> <exec executable="${cc}" dir="${storage.src}" failonerror="true"> <arg line="${cc.arg.line.prefix} -KPIC xyz.c -o ${cc.obj.dir}/xyz.o"/> </exec> The first exec complies xyz.c file and places in one directory and the 2nd once also compiles the same xyz.c with different compiler options and places it in a different directory, which is one level up as the top one. It would be very clumsy to write similar staments for all the c files which exist in multiple directories of the project, unless we have a way out define function like syntax in ant. <FunctionCall name="compileC"> <arg name="cfile" value="xyz"> <arg name="directory" value="/opt/objs" </FunctionCall> <Function name="compileC" parms="cFile, directory"> <exec executable="${cc}" dir="${directory}/" failonerror="true"> <arg line="${cc.arg.line.prefix} cfile.c -o ${cc.obj.dir}/../cfile.o"/> </exec> <exec executable="${cc}" dir="${directory}" failonerror="true"> <arg line="${cc.arg.line.prefix} -KPIC file.c -o ${cc.obj.dir}/cfile.o"/> </exec> </Function> This could be futher simiplified if in case for loop kind of syntax in place The workaround for this to write a custom tag which does internally call the Builtin tasks. But this is less portable and flexible. Not sure if this makes sense. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
