When I added support for copying files with spaces in their names, I
missed a case. On Mac (the only platform where we currently, in the
Oracle build, have a directory with space in it), when rebuilding images
after actually touching the source, the build fails with:
cp:
/Users/danielfuchs/workspaces/jdk/jdk10/build/macosx-x64/images/jdk/lib/missioncontrol/Java
Mission Control.app/Contents/Eclipse/jmc.ini: No such file or directory
This is caused by the $(call MakeDir, $(@D)) line in the install-file
macro not actually creating the parent directory before trying to copy
the file. This in turn was caused by two things:
First, if a target file that contains spaces, that is defined using the
? wildcard trick, exists when the makefile is parsed, make will resolve
those wildcards to spaces, so the target file variable ($@) will have
spaces in it instead of ?. This has the consequence that $(@D), which is
just a shortcut for $(dir $@) will actually apply the dir call on each
space separated entity in $@. So the first fix was to make sure the
input to $(dir ) is actually SpaceEncoded.
Second, the wildcard function seem to be doing some kind of clever
caching of results and this caching breaks down when there are spaces in
filenames. Because of this, if the argument of $(wildcard ) existed when
the makefile was parsed, but was then deleted as part of a prerequisite
rule, $(wildcard ) will still return the file as existing when called
from a subsequent recipe line. This only happens if the file argument to
wildcard contains spaces, so my best guess is that some string matching
is happening in some caching table and fails (but I haven't actually
checked the gnu make source). My fix for this is to change the MakeDir
macro so that it always runs mkdir if the target dir contains ?.
I also have modified the copy-files tests to reproduce this situation
and verified that the fix solves it there as well.
Bug: https://bugs.openjdk.java.net/browse/JDK-8190702
Webrev: http://cr.openjdk.java.net/~erikj/8190702/webrev.01/
/Erik
