From rkennke at redhat.com  Wed Feb 13 09:21:30 2013
From: rkennke at redhat.com (Roman Kennke)
Date: Wed, 13 Feb 2013 18:21:30 +0100
Subject: [RFC] Fix Zero and Shark builds
Message-ID: <1360776090.2524.22.camel@mercury>

First of all, let me tell you how great the new build machinery is: IT
ROCKS! Thanks for doing this!

These changes introduce the necessary configure- and make-foo to make
Zero and Shark builds work with the build-infra machinery. With this,
Zero and Shark builds are as easy as:

bash configure --with-jvm-variants=zero[shark]
make

it will check for existence of libffi and llvm, and use pkg-config and
llvm-config to figure out all required variables. This is basically
adopted from jdk/make/jdk_generic_profile.sh, and now integrated into
the build.

This only contains the source files, not the regenerated configure
scripts:

http://cr.openjdk.java.net/~rkennke/zero-build-infra/webrev.00/

Which brings up an interesting question (not sure if that has been
discussed before). Who is responsible to regenerating the configure
scripts after a change in the sources? Variances between versions of
autotools will like create a mess in the diffs and probably unforeseen
hiccups.

Also, a small change was required to be able to build images:

http://cr.openjdk.java.net/~rkennke/zero-build-infra-jdk/webrev.01/

Opinions? Can I have a bug-ID? Can I push this?

Best regards,
Roman



From volker.simonis at gmail.com  Thu Feb 14 06:24:55 2013
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 14 Feb 2013 15:24:55 +0100
Subject: [RFC] Fix Zero and Shark builds
In-Reply-To: <1360776090.2524.22.camel@mercury>
References: <1360776090.2524.22.camel@mercury>
Message-ID: <CA+3eh10eoTEqLGA6_3w5HD2wNDJyiyAWoBfFLt5vZMPtMuKhmw@mail.gmail.com>

On Wed, Feb 13, 2013 at 6:21 PM, Roman Kennke <rkennke at redhat.com> wrote:
> First of all, let me tell you how great the new build machinery is: IT
> ROCKS! Thanks for doing this!
>
> These changes introduce the necessary configure- and make-foo to make
> Zero and Shark builds work with the build-infra machinery. With this,
> Zero and Shark builds are as easy as:
>
> bash configure --with-jvm-variants=zero[shark]
> make
>
> it will check for existence of libffi and llvm, and use pkg-config and
> llvm-config to figure out all required variables. This is basically
> adopted from jdk/make/jdk_generic_profile.sh, and now integrated into
> the build.
>
> This only contains the source files, not the regenerated configure
> scripts:
>
> http://cr.openjdk.java.net/~rkennke/zero-build-infra/webrev.00/
>
> Which brings up an interesting question (not sure if that has been
> discussed before). Who is responsible to regenerating the configure
> scripts after a change in the sources? Variances between versions of
> autotools will like create a mess in the diffs and probably unforeseen
> hiccups.
>

That's a really interesting question. I'm pretty sure we will hit this kind
of problems soon for the ppc-aix-port as well when we will start with jdk8.

It would be very much appreciated if somebody form the build group
will provide some advice and guidance here:)

> Also, a small change was required to be able to build images:
>
> http://cr.openjdk.java.net/~rkennke/zero-build-infra-jdk/webrev.01/
>
> Opinions? Can I have a bug-ID? Can I push this?
>
> Best regards,
> Roman
>
>

From rkennke at redhat.com  Wed Feb 20 13:32:49 2013
From: rkennke at redhat.com (Roman Kennke)
Date: Wed, 20 Feb 2013 22:32:49 +0100
Subject: [RFC] Fix Zero and Shark builds
In-Reply-To: <511CA038.7050708@oracle.com>
References: <1360776090.2524.22.camel@mercury> <511CA038.7050708@oracle.com>
Message-ID: <1361395969.19150.80.camel@mercury>

> > These changes introduce the necessary configure- and make-foo to make
> > Zero and Shark builds work with the build-infra machinery. With this,
> > Zero and Shark builds are as easy as:
> >
> > bash configure --with-jvm-variants=zero[shark]
> > make
> >
> > it will check for existence of libffi and llvm, and use pkg-config and
> > llvm-config to figure out all required variables. This is basically
> > adopted from jdk/make/jdk_generic_profile.sh, and now integrated into
> > the build.
> >
> A couple of comments:
> 
> ARCH_DATA_MODEL is considered a legacy variable outside of hotspot. If 
> you look in hotspot-spec.gmk.in, we set it there specifically for the 
> hotspot build. The source for this value is in 
> common/autoconf/platform.m4 and it seems to me that several of the 
> values you are calculating should rather be set there (endian, libarch 
> etc). Do any of these need special treatment because of the ZERO[SHARK] 
> compiler? If not, I would like to have as many of them as possible just 
> translated from existing variables in hotspot-spec.gmk and if possible 
> handle the special cases in platform.m4.

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?

Best regards,
Roman



From rkennke at redhat.com  Thu Feb 21 03:26:30 2013
From: rkennke at redhat.com (Roman Kennke)
Date: Thu, 21 Feb 2013 12:26:30 +0100
Subject: [RFC] Fix Zero and Shark builds
In-Reply-To: <51260255.5000508@oracle.com>
References: <1360776090.2524.22.camel@mercury> <511CA038.7050708@oracle.com>
	<1361395969.19150.80.camel@mercury> <5125F89B.40909@oracle.com>
	<51260255.5000508@oracle.com>
Message-ID: <1361445990.2945.7.camel@mercury>

Am Donnerstag, den 21.02.2013, 21:17 +1000 schrieb David Holmes:
> 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.

So far, the only supported ppc64 in Hotspot is Zero. At least to my
knowledge. I am not sure why we need to explicitely link libstdc++
dynamically there though. I don't really see how this could affect
anything outside Zero. And yes, it probably does affect the upcoming
PPC64 port, but this needs to be sorted out anyway.


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

Probably not. Not sure how a standalone hotspot build works with the new
build-system. (I would be very happy to do this to reduce turnaround
even more.) What would I need to do? Move all Zero/Shark variables to
hotspot-spec.gmk.in ?

Thanks,
Roman



From volker.simonis at gmail.com  Fri Feb 22 01:14:09 2013
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 22 Feb 2013 10:14:09 +0100
Subject: [RFC] Fix Zero and Shark builds
In-Reply-To: <51260255.5000508@oracle.com>
References: <1360776090.2524.22.camel@mercury> <511CA038.7050708@oracle.com>
	<1361395969.19150.80.camel@mercury> <5125F89B.40909@oracle.com>
	<51260255.5000508@oracle.com>
Message-ID: <CA+3eh116DYVaLi-ySZurFn-+K8aquOR_dyYLpoADFncWDPfZQg@mail.gmail.com>

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