building langtools (extension of partial builds)

Magnus Ihse Bursie magnus.ihse.bursie at oracle.com
Mon Oct 29 11:57:10 PDT 2012


On 2012-09-18 18:49, Jonathan Gibbons wrote:
>
> For the record, this worked for me:
>
> ( mkdir -p build.new ; cd build.new ; sh 
> /w/jjg/work/tl/common/autoconf/configure 
> --with-override-langtools=$(cd .. ; pwd) )
>
> followed by
>
> make -f build.new/Makefile  langtools
If this turns out to be a common mode of operation, we should probably 
try to add support to it somehow.

Maybe we could add a simple script named "configure" in the langtools 
repo root, which would require a parameter
--with-toplevel=/w/jjg/work/tl
or something like that, and then calling /w/jjg/work/tl/configure with 
--with-override-langtools=<directory of the langtools configure script>
and all other configure arguments the user would like to pass. And 
possibly also overriding the output, to create a build/<configuration> 
directory under the current langtools repo instead. (This is currently 
not easy to do, but it would be simple to add a --with-build-dir or so 
to the top-level configure).

I have already created a thin wrapper in langtools/makefiles/Makefile, 
which will try to locate the top-level Makefile and run "make 
langtools". This could possibly be improved in many ways, to allow more 
fine-grained interaction with the langtools part of the build.

For the jdk repo, I have added a JDK_TARGET variable, so you can type 
"make jdk-only JDK_TARGET=libs-only" if you want to run the libs-only 
target in the jdk makefile.

>
> FWIW, it works well enough, but it does more than I need as a 
> langtools developer. I just need what is now builld/langtools/classes 
> in this new world; I don't need the *.{jar,zip} files to be 
> created/updated, with the exception of the bootstrap javac.  And, 
> because everything channels through the top level makefile, there 
> appears to be no easy way to build interim targets in 
> langtools/makefiles/Makefile, is that right?

I think the idea here is that when we transition to having smartjavac as 
default, the default mode of operation would be to have a jar file, not 
a directory full of class files, as default output. The new build system 
mimics this, even when not running with smartjavac.

But with that said, it might very well be the case that we are doing 
stuff in langtools that's only needed if you want to build an image. If 
so, we might want to consider moving that to a separate target in 
langtools, and only call it if we are building an image.

/Magnus



More information about the build-infra-dev mailing list