Dollar ($) expansion still needs attention

David Holmes david.holmes at oracle.com
Wed Feb 27 23:43:32 UTC 2013


On 28/02/2013 4:31 AM, Ioi Lam wrote:
> While we are cleaning this up, would it make sense to replace the
> maddening \ and $ with something like this?
>
>               sun/awt/motif/X11GB2312${DOLLAR}Decoder.class

Perhaps. Though there would not be anything to tell people that this 
variable exists and that they should use it.

I suspect that what we see now is that a variable that is subject to 
secondary expansion requires the \$$$$, while a variable not subject to 
secondary expansion requires \$$. Though I'm unsure how anything 
recently changed would have affected this aspect.

David

> - Ioi
>
>
> On 02/26/2013 06:47 PM, David Holmes wrote:
>> So ... nashorn pushed this change:
>>
>> http://hg.openjdk.java.net/jdk8/tl/diff/5b0b6ef58dbf/common/makefiles/MakeBase.gmk
>>
>>
>> which modified the way $ gets handled in a file name, and in doing so
>> completely broke many of the pre-existing escape sequences used for
>> dealing with nested classes (those with $ in their name). I'm not 100%
>> convinced that this actually relates to secondary expansion but ...
>>
>> Alan found and fixed both:
>>
>> 8008977: profiles build broken by Nashorn build changes
>>
>> and
>>
>> 8009029: SunEC provider classes ending up in rt.jar after Nashorn
>> build changes
>>
>> However we have now ended up in a situation where nobody knows how to
>> write the name of a nested class, without knowing how that name will
>> actually get processed. If you look in CreateJars.gmk you will find:
>>
>> RT_JAR_EXCLUDES += \
>> ...
>>         sun/awt/motif/X11GB2312.class \
>>         sun/awt/motif/X11GB2312\$$Decoder.class \
>>         sun/awt/motif/X11GB2312\$$Encoder.class \
>>         sun/awt/motif/X11GBK.class \
>>         sun/awt/motif/X11GBK\$$Encoder.class \
>>         sun/awt/motif/X11KSC5601.class \
>>         sun/awt/motif/X11KSC5601\$$Decoder.class \
>>         sun/awt/motif/X11KSC5601\$$Encoder.class \
>>
>> (which were modified to fix 8009029) and later:
>>
>> ifneq ($(OPENJDK_TARGET_OS), windows)
>>     CHARSETS_EXTRA_FILES:=sun/awt/motif/X11GBK.class \
>> sun/awt/motif/X11GB2312\$$$$Decoder.class \
>>                           sun/awt/motif/X11GB2312.class \
>> sun/awt/motif/X11KSC5601\$$$$Decoder.class \
>> sun/awt/motif/X11KSC5601\$$$$Encoder.class \
>> sun/awt/motif/X11GB2312\$$$$Encoder.class \
>>                           sun/awt/motif/X11GBK\$$$$Encoder.class \
>>                           sun/awt/motif/X11KSC5601.class
>> endif
>>
>> So the same file names are listed once with \$$ and once with \$$$$,
>> and they both have to be that way to work!
>>
>> This is untenable. There should only be one way to write the name of a
>> nested class file inside the makefile.
>>
>> FYI in Profiles.gmk when expanding foo/*.class I already had to do a
>> similar substitution as is now in ListPathsSafely:
>>
>> # Function to expand foo/*.class into the set of classes
>> # NOTE: Classfiles with $ in their name are problematic as that is the
>> # meta-character for both make and the shell! Hence the \$$$$
>> substitution.
>> # But note that if you echo these values they will NOT display as
>> expected.
>> class_list =  $(patsubst $(JDK_OUTPUTDIR)/classes/%,%,\
>>      $(foreach i,$(1), $(subst $$,\$$$$, $(wildcard
>> $(JDK_OUTPUTDIR)/classes/$i))))
>>
>>
>> So I'd like to understand why the nashorn change was made so that we
>> can determine how to get back to only having one way to specify file
>> names containing $
>>
>> David
>> -----
>>
>>
>



More information about the build-dev mailing list