RFR: 8072740: move closed jvm.cfg files out of open repo
David Holmes
david.holmes at oracle.com
Thu Mar 26 06:57:13 UTC 2015
On 26/03/2015 4:38 PM, Dean Long wrote:
> On 3/25/2015 3:42 PM, David Holmes wrote:
>> New webrev:
>>
>> http://cr.openjdk.java.net/~dholmes/8072740/webrev.v2/
>>
>> This doesn't define the ALT_JVMCFG_SRC in the open file - which makes
>> more sense for the clean up.
>>
>> I was unsure if $(wildcard xxx) would behave okay if xxx was an
>> undefined variable, but it seems to handle it okay.
>>
>
> That feels like we're depending on undefined behavior, so it could
No it means I don't know how it is defined to behave but it seems to be
working. :) Hopefully one of the build folk can chime in here with
something definitive. As far as I can tell an empty pattern matches
nothing - which is what we want.
> possibly behave differently in different versions of gcc. How about
This is make not gcc :)
> something like this instead:
>
> // Override with ALT_JVMCFG_SRC if defined.
> // ALT_JVMCFG_SRC must either be set to a file that exists or be undefined.
> ifdef ALT_JVMCFG_SRC
> JVMCFG_SRC := $(ALT_JVMCFG_SRC)
> endif
I thought about doing something like this but it has a side-effect on
the "alternative" side - you would have to set ALT_JVMCFG_SRC only for
those cases where the alternative file exists (or else add another
existence check on the open side).
I went for the combined minimal solution that seems to work.
Thanks,
David
> dl
>
>> Thanks,
>> David
>>
>> On 25/03/2015 7:08 PM, David Holmes wrote:
>>> I've been asked to make a change so a new webrev will be firthcoming.
>>>
>>> Thanks,
>>> David
>>>
>>> On 25/03/2015 1:43 PM, David Holmes wrote:
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8072740
>>>>
>>>> webrev: http://cr.openjdk.java.net/~dholmes/8072740/webrev/
>>>>
>>>> Simple fix, contributed by Dean Long, that allows the jvm.cfg file
>>>> to be
>>>> located in the "closed" location. The arm and ppc jvm.cfg files can
>>>> then
>>>> be moved to that "closed" location.
>>>>
>>>> Thanks,
>>>> David
>
More information about the build-dev
mailing list