building cacao as an additional VM

[Andrew Haley]

Matthias Klose wrote:
> 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.

It's wrong when running on CACAO, however it was built.

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

There's no alternative but a runtime check for the VM that it's running on.

Andrew.