Dollar ($) expansion still needs attention

[Kelly O'Hair]

Just FYI...

The  x+=y  is a unique make variable assignment, I think it evaluates the right or the entire variable
or something.

---
Also, as I recall, very vaguely, at one point in time, some of these Def*.gmk files would get included
multiple times in one make process. This caused issues and in some cases I had to add in the equivalent
of the C header file protection from multiple inclusions, e.g.

ifndef DEF_FOOBAR
  DEF_FOOBAR=true
  < All of Defs_foobar.gmk >
endif

The nested Defs*.gmk inclusions are a nightmare. So be careful.

-kto

On Feb 27, 2013, at 3:43 PM, David Holmes wrote:

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