RFR(M): 8046471: Use OPENJDK_TARGET_CPU_ARCH instead of legacy value for hotspot ARCH

[Erik Joelsson]

Looks fine to me.

/Erik

On 2014-06-12 23:18, Mikael Vidstedt wrote:
>
> I have now verified that the changes work just fine for the platforms 
> we build and test - both from the top level and when building hotspot 
> only. Taking suggestions on other tests to perform. And it would be 
> great if somebody could test the changes on on aix/ppc.
>
> So, kindly asking for "real"/final reviews of the changes:
>
> top: 
> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/top/webrev/
> hotspot: 
> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/hotspot/webrev/
>
> Cheers,
> Mikael
>
> On 2014-06-10 22:53, Mikael Vidstedt wrote:
>>
>> David,
>>
>> Thanks for the feedback. Essentially the logic in the 
>> make/<os>/makefiles/defs.make files needs to recognize and deal with 
>> two different use cases:
>>
>> 1. ARCH being set by the JDK build system to the value of 
>> OPENJDK_TARGET_CPU_ARCH, or
>> 2. no ARCH being set, in which case it needs to be populated - 
>> typically from uname
>>
>> Since Solaris and bsd both override ARCH they do not care about 
>> OPENJDK_TARGET_CPU_ARCH and effectively always go through case 2.
>>
>> Linux/x86 is where most of the difference (and confusion) is, but I 
>> think aix/ppc64 will also change slightly since the ARCH value will 
>> go from ppc64 to ppc. I've tried to make the relevant changes, but I 
>> cannot verify that they actually work. cc:ing the ppc-aix list in the 
>> hope that somebody can help out with that.
>>
>>
>> Summing it up, I have the following two webrevs:
>>
>> top: 
>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/top/webrev/
>> hotspot: 
>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/hotspot/webrev/
>>
>> With these changes I can build the normal platforms, but more 
>> verification is needed - esp. building hotspot only. Meanwhile 
>> feedback is much appreciated!
>>
>> Cheers,
>> Mikael
>>
>> On 2014-06-10 19:45, David Holmes wrote:
>>> Hi Mikael,
>>>
>>> This seems a reasonable proposal to me. We have an over-abundance of 
>>> "arch" variables and values, so reducing that is a good aim.
>>>
>>> As you note the main flow-on effect here is that the hotspot 
>>> makefiles have to be updated for the cases where 
>>> OPENJDK_TARGET_CPU_ARCH and OPENJDK_TARGET_CPU_LEGACY differ so that 
>>> it still sets LIBARCH, BUILDARCH, SRCARCH correctly. I think only 
>>> x86 has that issue.
>>>
>>> Wouldn't it be nice if we could get rid of i386, i586, i686 etc both 
>>> internally and in the build artifacts and bundles!
>>>
>>> Cheers,
>>> David
>>>
>>> On 11/06/2014 10:11 AM, Mikael Vidstedt wrote:
>>>>
>>>> All,
>>>>
>>>> I need some feedback and comments on the below fix:
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8046471
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.00/webrev/
>>>>
>>>> Background:
>>>>
>>>> When configuring the hotspot build the build system sets up the ARCH
>>>> variable to reflect the target cpu. Currently the value is initialized
>>>> to OPENJDK_TARGET_CPU_LEGACY, which is the internal legacy cpu 
>>>> name. For
>>>> example, on x86 64-bit this is amd64 on linux (but x86_64 on mac). The
>>>> goal in the new (JDK) build system is to have the "legacy" value
>>>> gradually removed in favor of the other variables.
>>>>
>>>> Discussion:
>>>>
>>>> The two candidate variables to base ARCH on are as far as I can tell
>>>> OPENJDK_TARGET_CPU and OPENJDK_TARGET_CPU_ARCH. Of the two
>>>> OPENJDK_TARGET_CPU_ARCH is the more "stable" one, with a single, well
>>>> defined value per cpu family { arm, ppc, s390, sparc, x86 }. Together
>>>> with ARCH_DATA_MODEL/LP64 that information should be enough for the
>>>> Hotspot build system to do its thing. Note: ARCH is currently 
>>>> ignored on
>>>> solaris and bsd - it's overridden at the top of the respective
>>>> make/<os>/makefiles/defs.make files.
>>>>
>>>> Before I go too far with this though I'd like to get some feedback on
>>>> whether or not this is the right approach and what the exact value
>>>> should be. Depending on the outcome of that the Hotspot build 
>>>> system may
>>>> have to be updated for some platforms to support the new value(s).
>>>>
>>>> Thanks,
>>>> Mikael
>>>>
>>
>