Erik:
Looks good to me as well.
Tim
On 11/15/17 07:52, Daniel Fuchs wrote:
Thanks for that Erik!
It's been annoying me for a couple of days :-)
I have imported your patch locally in my repo and it seems to
be working fine.
Hopefully someone from the build team will give you a thumbs up!
best regards,
-- daniel
On 14/11/2017 22:35, Erik Joelsson wrote:
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