Review Request: 7141246 build-infra merge: Introduce new JVM_VARIANT* to control which kind of jvm gets built (original) (raw)

David Holmes david.holmes at oracle.com
Mon Mar 19 01:21:12 UTC 2012

Hi Erik,

On 16/03/2012 7:24 PM, Erik Joelsson wrote:

http://cr.openjdk.java.net/~erikj/7141246/webrev.03/ <http://cr.openjdk.java.net/%7Eerikj/7141246/webrev.03/>

Looks fine.

Removed all references to "minimal". Also cleaned up the defaults section a bit.

Minor nit, when you say:

On 32 bit we build server and client, on 64 bit just server.

the OS isn't actually relevant. If we ask for a 32-bit build then we build both client and server; if we ask for a 64-bit build then we build server only (by default).

So AFAICS the only platform dependent part here is adding kernel on Windows - right? If so then once we do the kernel->minimal transition this can be refactored into the defaults section of the top-level defs.make

David

/Erik On 2012-03-14 09:17, Erik Joelsson wrote:

On 2012-03-14 06:00, David Holmes wrote: Hi Erik, I find it confusing to convert KERNELBUILD->(JVMVARIANTMINIMAL=true) and then check for JVMVARIANTMINIMAL, instead of just defining JVMVARIANTKERNEL. Particularly when KERNEL is used in a bunch of other variables. I can agree that it seems weird. What is the timeframe for removing kernel and introducing minimal in jdk8? If it's far off I can see it making sense for us to revert the name MINIMAL to KERNEL for the whole project. It will be more work converting back later though. make/Makefile Are the Shark/Zero folk okay with the shark/zero changes? If I understand correctly, today if SHARKBUILD==true then ZEROBUILD==true, but in the new scheme JVMVARIANTZEROSHARK and JVMVARIANTZERO are distinct (but the name ZEROSHARK implies ZERO and SHARK). I have not checked with them specifically, no. I'm guessing that the old variables were defined like that because it made the checks easy to write since zero and shark share a lot of settings in the makefiles. As I understand it, what we would like to express with the JVMVARIANT is a configuration resulting in a separate jvm binary. If you define two or more variants, you will end up with that many binaries. This is already true for SERVER, CLIENT and KERNEL. We would like all the variants to be controlled and expressed in the same way. These changes unfortunately won't take us all the way, but it's a first step. /Erik --- /make/defs.make 74 ifeq ($(ZEROBUILD)$(KERNELBUILD)$(SHARKBUILD),) 75 # A default is needed 76 ifeq ($(BUILDCLIENTONLY), true) 77 JVMVARIANTS:=client 78 JVMVARIANTCLIENT:=true 79 endif 80 # Further defaults are platform and arch specific I don't understand why we would only need a default in the BUILDCLIENTONLY case. Is this just to avoid replicating the BUILDCLIENTONLY check in the platform specific makefiles? David -----

/Erik You seem to have included the MINIMAL VM changes in here. Those changes have not been pushed to the mainline and are not yet to be pushed. If you want to push these build-infra changes you will need to factor out the MINIMAL VM stuff - else wait. David

More information about the build-dev mailing list