Review Request: 7141246 build-infra merge: Introduce new JVM_VARIANT* to control which kind of jvm gets built
david.holmes at oracle.com
Sun Mar 18 18:21:12 PDT 2012
On 16/03/2012 7:24 PM, Erik Joelsson wrote:
> Removed all references to "minimal". Also cleaned up the defaults
> section a bit.
Minor nit, when you say:
# On 32 bit <OS-NAME> 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
> 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
>>> KERNEL_BUILD->(JVM_VARIANT_MINIMAL=true) and then check for
>>> JVM_VARIANT_MINIMAL, instead of just defining JVM_VARIANT_KERNEL.
>>> 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.
>>> Are the Shark/Zero folk okay with the shark/zero changes? If I
>>> understand correctly, today if SHARK_BUILD==true then
>>> ZERO_BUILD==true, but in the new scheme JVM_VARIANT_ZEROSHARK and
>>> JVM_VARIANT_ZERO 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
>> JVM_VARIANT 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.
>>> 74 ifeq ($(ZERO_BUILD)$(KERNEL_BUILD)$(SHARK_BUILD),)
>>> 75 # A default is needed
>>> 76 ifeq ($(BUILD_CLIENT_ONLY), true)
>>> 77 JVM_VARIANTS:=client
>>> 78 JVM_VARIANT_CLIENT:=true
>>> 79 endif
>>> 80 # Further defaults are platform and arch specific
>>> I don't understand why we would only need a default in the
>>> BUILD_CLIENT_ONLY case. Is this just to avoid replicating the
>>> BUILD_CLIENT_ONLY check in the platform specific makefiles?
>>>>> You seem to have included the MINIMAL VM changes in here. Those
>>>>> 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.
More information about the hotspot-runtime-dev