[7u60] RFR 8024648 : 8016131 breaks Zero port

[David Holmes]

To expand on a solution for this ...

Note that in vm.make and gcc.make the only uses of the JVM_VARIANT 
variables relates to ZERO and ZEROSHARK. That is the real problem in my 
view (it was natural to use them as they were very prominent).

Looking through the build process it seems to me that in the generated 
flags.make we will have:

include zero|shark.make
include gcc.make

And in zero|shark.make we have TYPE=ZERO or TYPE=SHARK. So TYPE can be 
used in gcc.make instead of the JVM_VARIANT_* variable. (BUILDARCH will 
also be zero but that doesn't help with shark.)

Aside: note that here zero or shark is the VARIANT but that isn't 
exposed in the generated makefiles as the VARIANT is already implicit in 
the path to which the file was generated eg 
hotspot/<os>_<arch>_<variant>/product

Similarly the generated vm.make will include flags.make before the repo 
version of vm.make so it too can use TYPE to identify ZERO or SHARK.

If I knew how to build zero/shark I'd test this out. :(

David
-----

On 7/02/2014 3:14 PM, David Holmes wrote:
> I have a concern here.
>
> First this general situation is a mess. We started adding the new-build
> support in hs24 but JDK 8 is using hs25, so all this SPEC and
> JVM_VARIANT stuff is completely unwanted in JDK 7u. My preference here
> would be to get this stuff backed out of 7u and return to a completely
> configure-ignorant build system. That said I'm not sure that is really
> the issue with ZERO/SHARK builds.
>
> My concern with the proposed patch is that defs.make is not intended to
> be included by every other Makefile and/or .make file. We all know by
> now that the hotspot build system is complex, convoluted and fragile.
> When you do a hotspot build there are multiple nested sub-makes
> involved, as well as build file generation and use. The "big picture"
> intent is that defs.make contains all the high-level stuff needed by the
> "top" level makefile targets. buildtree.make will then generate other
> .make files using that information. It is very difficult to see exactly
> which .make file will get used by which phase of the overall build.
> Unfortunately this leads to a tendency where if a "low-level" file needs
> access to X, which is defined in defs.make, then the "solution" is just
> to include defs.make in that file. We did the same thing for
> buildtree.make in JDK 8. But I have reservations about also doing it for
> gcc.make and vm.make. I think it is the wrong solution - we should be
> passing the needed variables/values through the files generated by
> buildtree.make.
>
> If this was to go ahead as-is I would want to know that there has been a
> comparison of all the build commands before and after to ensure no
> unintended changes have been introduced. A set of successful builds is
> not in itself sufficient.
>
> David
>
> On 7/02/2014 8:10 AM, Alejandro E Murillo wrote:
>> I  forgot to change the "subject".
>> The change is and has been approved for 7u60 (hs24.60)
>> Thanks
>>
>> Alejandro
>>
>> On 2/6/2014 3:03 PM, Alejandro E Murillo wrote:
>>>
>>> can we get 2  hotspot reviewers quickly  check this change ?
>>> thanks
>>> Alejandro
>>>
>>> -------- Original Message --------
>>> Subject:     Re: Question on 8024648 : 8016131 breaks Zero port
>>> Date:     Thu, 6 Feb 2014 16:21:29 -0500 (EST)
>>> From:     Andrew Hughes <gnu.andrew at redhat.com>
>>> To:     Alejandro E Murillo <alejandro.murillo at oracle.com>
>>> CC:     Seán Coffey <sean.coffey at oracle.com>, Omair Majid
>>> <omajid at redhat.com>, jdk7u-dev at openjdk.java.net
>>>
>>>
>>>
>>> ----- Original Message -----
>>>
>>>
>>> Here's the webrev:
>>>
>>> http://cr.openjdk.java.net/~andrew/jdk7u/8024648/
>>>
>>> My OpenJDK username is andrew (should already be included in the commit)
>>>
>>> The changes are as follows:
>>>
>>> * Bring in defs.make to a number of makefiles which expect
>>> JVM_VARIANT_ZERO
>>> or JVM_VARIANT_ZEROSHARK to be set, but don't parse the makefile that
>>> sets
>>> it. This is a regression caused by the new build which instead sets
>>> these
>>> via configure and $(SPEC). There is code for handling the old build
>>> (ZERO_BUILD=true) in defs.make but it isn't brought in. (see 7141246)
>>> * Update the call_wrapper function following 8024648.
>>>
>>> I've updated the bug summary to reflect that it fixes changes from both
>>> bugs, but we can split them into two separate bugs if you prefer.
>>> Without
>>> the 7141246 fix, the build fails in seconds.
>>>
>>> With the webrev applied:
>>>
>>> $ /mnt/builder/hsx-jdk7u/j2sdk-image/bin/java -version
>>> openjdk version "1.7.0-internal"
>>> OpenJDK Runtime Environment (build
>>> 1.7.0-internal-andrew_2014_02_06_19_43-b00)
>>> OpenJDK 64-Bit Zero VM (build 24.80-b01, interpreted mode)
>>>
>>> $ /mnt/builder/hsx-jdk7u/j2sdk-image/bin/java HelloWorld
>>> Hello World
>>>
>>>
>>