langtools build and genstubs task

[Jonathan Gibbons]

On 06/01/2010 04:36 AM, Andrew John Hughes wrote:
> In the langtools build, the genstubs tool is passed a classpath:
>
>          <genstubs
>              srcdir="${import.jdk.src.dir}" destdir="${build.genstubs.dir}"
>              includes="${import.jdk.stub.files}"
>              fork="true"
> classpath="${build.toolclasses.dir}:${build.bootstrap.dir}/classes:${ant.home}/lib/ant.jar"
> 	/>
>
> which it uses for a forked process that runs genstubs itself.
>
> However, if fork is set to false the classpath given by:
>
>          <taskdef name="genstubs"
>                   classname="GenStubs$$Ant"
>                   classpath="${build.toolclasses.dir}/"/>
>
> which seems to work in some cases, but only if Ant has access to the
> 1.6 javax.tools classes.  Even if these classes are available, they
> will be the ones belonging to the boot VM and not the bootstrap
> classes.
>
> Should this classpath not be set to the same as that passed to
> genstubs as in http://hg.openjdk.java.net/icedtea/jdk7/langtools/rev/681f1f51926f
> ?
>    

Possibly.  Getting genstubs to work was enough of a challenge that I was 
pleased to get it running with fork=true without taking it to the next 
step of fork=false. One minor issue is that putting langtools classes on 
a classpath is generally not acceptable for anyone building on a Mac -- 
which is why you see such liberal use of the bootclasspath in the 
langtools build.xml file.

Also, I'd be surprised if you need the ant classes on the classpath for 
a taskdef -- are they not available anyway?

Finally, I'm not sure if this is an issue or if this assumption is 
already implicit in the rest of the Ant file, but by putting the 
langtools classes on the taskdef classpath, you are assuming that Ant's 
JVM can handle them -- which is presuming a certain level of JVM used to 
run Ant.

-- Jon