[RFC] Fix Zero and Shark builds

[Volker Simonis]

Good catch! This will indeed affect the upcoming AIX/ppc64 port but I
think it can be easily fixed.

As far as I understand, the intention of the change is to statically
link libstsc++ for the Zero build on ppc64, so why don't change it
this way:

 242 ifeq ($(JVM_VARIANT_ZEROSHARK), true)
 243   STATIC_CXX = false
 244 else
       ifeq ($(JVM_VARIANT_ZERO), true)
 245     ifeq ($(OPENJDK_TARGET_CPU), ppc64)
 246       STATIC_CXX = false
 247     else
 248       STATIC_CXX = true
 249     endif
       endif
 250 endif

Thank you and best regards,
Volker

On Thu, Feb 21, 2013 at 12:17 PM, David Holmes <david.holmes at oracle.com> wrote:
> So far I've looked at the hotspot changes - but really this should also go
> to hotspot-dev - cc'd
>
> I only see one change that isn't confined to zero/shark specific code and
> that is in make/linux/makefiles/vm.make:
>
>   ifeq ($(JVM_VARIANT_ZEROSHARK), true)
>     STATIC_CXX = false
>   else
> !   ifeq ($(OPENJDK_TARGET_CPU), ppc64)
>       STATIC_CXX = false
>     else
>       STATIC_CXX = true
>     endif
>   endif
>
> this may conflict with the incoming AIX/ppc64 port.
>
> My other comment on these changes is that you've now made the zero hotspot
> build dependent on being part of a complete build - ie there must be a
> spec.gmk/hotspot-spec.gmk for these variables to be defined. You won't be
> able to build hotspot stand-alone. Is that what you intended?
>
> David
> -----
>
>
>
> On 21/02/2013 8:36 PM, Erik Joelsson wrote:
>>
>>
>>
>> On 2013-02-20 22:32, Roman Kennke wrote:
>>>
>>>
>>> Thanks for the review! I made the following changes:
>>>
>>> - I moved all platform-foo to platform.m4, in
>>> PLATFORM_SETUP_LEGACY_VARS. Little problem: in this section I don't know
>>> about JVM_VARIANTS_ZERO yet, therefore I set those vars unconditionally.
>>> (But I propagate them to Make conditionally, see below). *However* those
>>> variables might actually be useful for non-Zero builds, if you look at
>>> the places where they're used, in non-Zero builds we find hardcoded
>>> values/strings for the various platforms, where the Zero way seems more
>>> elegant here.
>>> - I replaced ZERO_ENDIANNESS with the equivalent
>>> OPENJDK_TARGET_CPU_ENDIAN.
>>> - I replaced ARCH_DATA_MODEL with OPENJDK_TARGET_CPU_BITS.
>>> - I replaced ZERO_LIBARCH with OPENJDK_TARGET_CPU_LEGACY_LIB.
>>> - ZERO_ARCHFLAG is still needed for build on s390, to enable the correct
>>> ABI (by setting -m31).
>>> - ZERO_ARCHDEF is needed to get in the correct -DAMD64 or whatever
>>> setting (which are otherwise hardcoded in the various platform_XXX.in
>>> files in non-zero builds -- you/we might want to re-think this).
>>>
>>> Those changes also require some changes in the hotspot tree. See webrevs
>>> below.
>>>
>>> Re: Mike's suggestion: I set the variables in spec.gmk conditionally
>>> now. However, the resulting spec.gmk does have the conditions and
>>> var-setting code still in it, i.e. the zero-related code does not
>>> disappear.
>>>
>>>> Where is INCLUDE_SA supposed to be set? I know it was handled in
>>>> Defs-[os].gmk files in the old build, but in the new I would assume
>>>> configure should be setting it.
>>>
>>> it is set in jdk/common/Defs-$PLATFORM.gmk. As per David's suggestion, I
>>> will not touch this for now. It is only required for images-builds... so
>>> not super-critical - for the time being.
>>>
>>> Webrevs:
>>> http://cr.openjdk.java.net/~rkennke/zero-build-infra/webrev.03/
>>> http://cr.openjdk.java.net/~rkennke/zero_build_infra_hotspot/webrev.01/
>>>
>>> How's this now?
>>>
>> That looks much cleaner, thank you. If the hotspot team is ok with
>> renaming the variables in the hotspot makefiles, I'm fine with that too,
>> but it's not my decision. If they aren't, you can still set the hotspot
>> specific variables based on the ones from configure in
>> hotspot-spec.gmk.in. From the build group this is ok. You will still
>> need an official jdk8 reviewer to look at it, and the hotspot changes
>> need someone from hotspot.
>>
>> /Erik
>>
>