> From: James Duncan Davidson [mailto:[EMAIL PROTECTED] > > On 12/6/00 1:51 AM, "Peter Donald" <[EMAIL PROTECTED]> wrote: > > > +1 > > > > It would be very very useful to integrate it for those poor > souls who don't > > choose to use jikes ;) I would like to see Javac to become > a facade for > > lower level compilers. ie - instead of having logic for jikes/javac > > modern/javac classic/microsoft/gnu/symantec compilers we > should instead > > place the code for these in seperate places and effectively > pass them a > > hashmap of properties post resolution in javac task. So once > > classpath/bootpath is resolved and any dependencies zapped > we should pass > > the hashmap with something like > > Righto. I totally agree with you on that. The Javac task would be, in > effect, several (on the order of 10 or so) class files by > doing that, but > that would be fine by me if we had a better way of managing all these > options. >
A simple initial solution would be to redifine Javac.java with subclasses for the different compilers. If you look at the code, the only difference is one or two methods, the rest is common code. Initially, <javac> should just look at the magic properties and just instantiate the correct subclass. What I would like is to generalize that instantiation as part of the work of <taskdef>: <taskdef name="javac" > <classname name="org.apache...Classic" if="build.compiler=classic"/> <classname name="org.apache...Jikes" if="build.compiler=jikes"/> <classname name="org.apache...Modern" /> </taskdef> Adding support for more compiler is just adding the respective class and more definitions here. Once we have this mechanism, we can do the same thing for other "generic" tasks. For example, Source control management, which we had some generic task defined at some point. Jose Alberto
