RFR (S): 8221880: Better customization for Windows RC properties FileDescription and ProductName

Erik Joelsson erik.joelsson at oracle.com
Thu Apr 4 13:57:21 UTC 2019


Hello,

On 2019-04-04 00:10, Langer, Christoph wrote:
> Hi Erik,
>
>> Looking closer at what we are doing, we are actually overriding
>> JDK_RC_PLATFORM_NAME as well, and there are a couple of direct
>> references to that variable in our custom makefiles. So I will still
>> need to update those if this goes in.
> Ok, but I think then we can/will keep JDK_RC_PLATFORM_NAME, no?
That would work, I think. We could then consider reworking our internal 
usage on our own time, if we wanted to. That would be the least intrusive.
>> In OpenJDK builds, the current strings evaluate to "OpenJDK Platform"
>> and for Oracle builds "Java(TM) Platform SE". It makes me curious as to
>> what you need to modify the string to?
> We want to print "SapMachine" there, see this commit:
> https://github.com/SAP/SapMachine/commit/e70a2bcb8a813bfca7adf82590a4427114af88a6#diff-00a92a44400757c2a70383c1b51ab8fa
>
> I would also be beneficial, if we could add a configure option for MACOSX_BUNDLE_NAME_BASE and MACOSX_BUNDLE_ID_BASE. We have a diff there as well:
> https://github.com/SAP/SapMachine/commit/d5df3b2c65fd8b833989375886640433ee9fa0f1#diff-ac0146eb7428c83f99766e2a13ff1b17
This makes me wonder why you don't also want to change the PRODUCT_NAME 
to SapMachine. Wouldn't it make more sense to have it all match? Or are 
you worried about compatibility issues if users expect the value 
OpenJDK? At least Oracle and OpenJDK builds have different values there 
already.
> Or are there maybe other hooks to customize these kinds of properties?
No other hooks that I know of. If you need customization, please add 
configure parameters. We haven't added any only because nobody has 
needed such customization yet.
> In any case, if it comes to a push of this change, I'd then let you do it to coordinate with your internal infrastructure ��

OK, I can do that if needed, but if we find a solution where it's not, 
I'm happy to let you push yourself. :)

/Erik

> Thanks
> Christoph
>
>> On 2019-04-03 14:33, Langer, Christoph wrote:
>>> Hi Erik,
>>>
>>> please see this new webrev:
>> http://cr.openjdk.java.net/~clanger/webrevs/8221880.1/
>>> I would now add a new configure flag --with-jdk-rc-name. By default, it is
>> unset and JDK_RC_NAME would be set to $PRODUCT_NAME
>> $JDK_RC_PLATFORM_NAME. I think this change would not create the need
>> for any modification to current build calls.
>>> One additional point that I was thinking about: Shouldn't we maybe
>> remove JDK_RC_PLATFORM_NAME from version-numbers at all and hard
>> code the value "Platform" in make/autoconf/jdk-version.m4?
>>> /Christoph
>>>
>>>
>>>> -----Original Message-----
>>>> From: Langer, Christoph
>>>> Sent: Mittwoch, 3. April 2019 16:25
>>>> To: 'Erik Joelsson' <erik.joelsson at oracle.com>; build-
>> dev at openjdk.java.net
>>>> Subject: RE: RFR (S): 8221880: Better customization for Windows RC
>>>> properties FileDescription and ProductName
>>>>
>>>> Hi Erik,
>>>>
>>>> thanks for the information. Now I also understand your constraints ��
>>>>
>>>> I think I'll then try to come up with some configure flag for setting
>>>> JDK_RC_NAME. And I'll see if I can do it in a way that you would not need
>> to
>>>> change something in your internal setup.
>>>>
>>>> /Christoph
>>>>
>>>>> -----Original Message-----
>>>>> From: Erik Joelsson <erik.joelsson at oracle.com>
>>>>> Sent: Mittwoch, 3. April 2019 16:18
>>>>> To: Langer, Christoph <christoph.langer at sap.com>; build-
>>>>> dev at openjdk.java.net
>>>>> Subject: Re: RFR (S): 8221880: Better customization for Windows RC
>>>>> properties FileDescription and ProductName
>>>>>
>>>>> Hello Christoph,
>>>>>
>>>>> I understand your problem, but a complicating factor here is that the
>>>>> version-numbers file is currently formatted as a properties file and we
>>>>> do consume it as such in other places. While we don't specifically look
>>>>> for this property there, I think it sets a bad precedent if we let it
>>>>> become a shell script instead. Could you find a solution without
>>>>> variable references in version-numbers?
>>>>>
>>>>> We do override PRODUCT_NAME for our builds, but we do not do it by
>>>>> patching the version-numbers file. We do it through the custom
>> extension
>>>>> hooks in configure. With your change here, that would no longer work
>>>>> unless we override this new JDK_RC_NAME variable explicitly.
>>>>>
>>>>> I guess I would be OK with JDK_RC_NAME="OpenJDK Platform", but we
>>>> will
>>>>> need a corresponding internal fix very quickly, so please keep me
>>>>> updated when such a change is pushed.
>>>>>
>>>>> /Erik
>>>>>
>>>>> On 2019-04-03 01:06, Langer, Christoph wrote:
>>>>>> Hi,
>>>>>>
>>>>>> In our downstream build, I'd like to be able to set/customize the value
>> for
>>>>> the Windows RC properties "ProductName" and "FileDescription" via the
>>>>> version-numbers file. These values manifest in Windows executable
>>>>> properties.
>>>>>> During the build ProductName gets set to "OpenJDK Platform 13" and
>>>>> FileDescription will be "OpenJDK Platform binary". This value is obtained
>> by
>>>>> concatenating \$(PRODUCT_NAME) \$(JDK_RC_PLATFORM_NAME) in
>>>> flags-
>>>>> other.m4. Both variables get set in version-numbers. So, if I was to
>>>> customize
>>>>> the properties, I could change PRODUCT_NAME and
>>>>> JDK_RC_PLATFORM_NAME in version-numbers. However, modifying
>> the
>>>>> former is no good idea since it is used ubiquitously and has unwanted
>> side
>>>>> effects. On the other hand, I could make an adaption to flags-other.m4,
>> but
>>>>> that diff would be hidden and not in a central place where I'd expect
>> such
>>>>> customizing diffs.
>>>>>> So, please review this small fix, which allows for modifying these RC
>>>>> properties in version-numbers. The default behavior won't be changed.
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8221880
>>>>>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8221880.0/
>>>>>>
>>>>>> Thanks
>>>>>> Christoph
>>>>>>


More information about the build-dev mailing list