[RFC] Fix Zero and Shark builds

[Christian Thalinger]

On Feb 21, 2013, at 4:15 AM, David Holmes <David.Holmes at oracle.com> wrote:

> On 21/02/2013 9:26 PM, Roman Kennke wrote:
>> 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.
> 
> Ok. Just wanted to flag it.
> 
>>> 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 ?
> 
> Hotspot has always been "self-configuring" on the build side. You can set a few variables to influence things but for the most part it detects things at build time. With the new build system hotspot was made "configure-aware". It was changed to include the spec.gmk file if it existed and the setting of variables potentially set by configure (and so in the spec.gmk file) was only done if not already set. Hence the two build approaches can co-exist.
> 
> I don't know how a zero build was previously initiated but I could imagine it was something like:
> 
> make ZEROARCH=zero <some-zero-target>

Close:  JVM_VARIANT_ZERO=true ZERO_BUILD=true; and a couple more.

-- Chris

> 
> then the zero-target together with the ZEROARCH value would trigger the right build logic to  set all the necessary Zero flags. To maintain this you just need to be prepared for values to have been pre-set via spec.gmk.
> 
> David
> -----
> 
> 
>> Thanks,
>> Roman
>> 
>>