Thanks Erik. Another review please?

Cheers,
Mikael

On 2014-06-12 23:56, Erik Joelsson wrote:
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





Reply via email to