building cacao as an additional VM

[Matthias Klose]

Andrew Haley schrieb:
> Matthias Klose wrote:
>> Triggered by archive administrators and security people who don't want to care
>> about two copies of the OpenJDK code in a distribution, I tried to build cacao
>> as additional VM in the same source package and avoiding separate builds. You
>> can now call:
>>
>>   $ java -version
>>   java version "1.6.0_0"
>>   OpenJDK Runtime Environment (IcedTea6 1.4) (6b14-0ubuntu18)
>>   OpenJDK Server VM (build 14.0-b08, mixed mode)
>>
>>   $ java -cacao -version
>>   java version "1.6.0_0"
>>   OpenJDK Runtime Environment (IcedTea6 1.4) (6b14-0ubuntu18)
>>   CACAO (build 0.99.3+hg, compiled mode)
>>
>> The cacao bits are installed in <top>/jre/lib/<arch>/cacao, cacao is configured
>> like for the cacao build in IcedTea, the cacao-alternate-vm patch replaces the
>> icedtea-cacao patch, cacao-jni-version needs applied to the cacao sources.
>> The file jvm.cfg.in needs an additional line '-cacao KNOWN'.
>>
>> There is no configure/make stuff for IcedTea yet; I'm currently assembling this
>> directly in the packaging.
>>
>> Doing the same with Zero and with Shark? Didn't check yet, but maybe this would
>> need a copy of openjdk/hotspot to openjdk/zero, so that patches are applied for
>> the latter only.
>>
>> Ok to checkin these patches (without applying them)?
> 
> This is wrong.  CACAO should report
> 
>   java version "1.6.0_0"
>   IcedTea6 Runtime Environment (pre-1.5-r92c4cc753f06) (foo.b14.baz-123)
>   CACAO (build 0.99.3, JIT mode)

this is only wrong for hotspot builds, not for zero builds.

the runtime is hardcoded in the version template, using
System.getProperty("java.runtime.name") to differentiate between the two just
returns the hardcoded name, which is Hotspot for Hotspot builds. Any suggestions?

  Matthias