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

[David Holmes]

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 <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

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
>>> 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.
>>> make/Makefile
>>>
>>> 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.
>>
>> /Erik
>>> ---
>>>
>>> /make/defs.make
>>>
>>> 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?
>>>
>>> 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
>>>>