RFR: JDK-8199749: Debug symbols are not copied to exploded image on Mac

[Magnus Ihse Bursie]

> 17 mars 2018 kl. 00:16 skrev Erik Joelsson <erik.joelsson at oracle.com>:
> 
> Debug symbols are by default external and the idea is that we copy them to the exploded image together with the native libraries, to have them available for debugging. This logic fails on Windows and Mac due to some intricate make dependency complications. On Windows this fails on the initial build already, on Mac the problem only appears if you make a change to a source file and rebuild incrementally. On both, if you rebuild again, the files get copied.
> 
> On Solaris and Linux we symlink these files instead of copying, so after the first build, the symlinks do not need to be recreated, which is why this isn't an issue there.
> 
> The underlying cause for this is that we are trying to trick make into correctly tracking dependencies when a rule has multiple targets. The link rule creates both the native library as well as the debuginfo files. A rule like that is always causing trouble in some way but various workarounds exist. Currently we work around it by adding this declaration:
> 
> $$($1_DEBUGINFO_FILES): $$($1_TARGET)
> 
> This trips up make if DEBUGINFO_FILES already exists, since there is no recipe, make will not consider DEBUGINFO to have been updated just because TARGET was rebuilt. If we add a recipe, make will consider DEBUGINFO to have changed. The obvious recipe is a simple touch on DEBUGINFO. That way we also guarantee that the DEBUGINFO is newer than TARGET so the rule doesn't get executed again on the next run.
> 
> This whole type of workaround for dealing with multiple files created by the same rule has a flaw. If something external deletes a DEBUGINFO file, it would currently not be recreated. In the new solution it would be touched as an empty file, which is even worse. To fix this, I've added a parse time check on the DEBUGINFO files and if either of them are gone, the TARGET is explicitly deleted. This forces a rebuild of both TARGET and DEBUGINFO.
> 
> While at it, I noticed that the import library on Windows suffers from the same problem so applied the same fix there.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8199749
> 
> Webrev: http://cr.openjdk.java.net/~erikj/8199749/webrev.01/index.html <http://cr.openjdk.java.net/~erikj/8199749/webrev.01/index.html>

Looks good to me.

/Magnus

> 
> /Erik
>