Looks ok. Going forward, do you think we would be helped by a specially crafted native binary that does this for us with a single call? Something like the Windows path converter, but available on all platforms?
/Magnus > 20 apr. 2016 kl. 17:20 skrev Erik Joelsson <[email protected]>: > > Unfortunately, this did not work well. The problem with the added "&& wait" > materializes if the caller of ExecuteWithLog tries to pipe the output of that > command, which we do frequently on Windows. To solve it, another level of > parentheses are needed. Unfortunately this adds another shell process for > each call, which makes the Windows build slightly slower again. I don't see > any other solution however. > > Webrev: http://cr.openjdk.java.net/~erikj/8154326/webrev.02/ > > /Erik > >> On 2016-04-19 14:32, Erik Joelsson wrote: >> Hello, >> >> After switching to the new hotspot build, we have seen some sporadic build >> errors related to the generation of dtrace JvmOffsets.h file on Solaris. The >> errors look like a compile target that depends on the header file fails >> because the header file is either empty or incomplete. I have managed to >> reproduce this by running this particular part of the build in a loop within >> 5 minutes. >> >> The header file generation uses the rather new ExecuteWithLog macro, which >> uses the also rather new ">(tee logfile)" construct to save output to a log >> file while still echoing both stderr and stdout separately to the console. >> It seems however, that when using this construct, bash spawns background >> processes which may not be done when the main process is done. >> >> I have noted a similar effect when switching to this construct for the main >> makefile build.log. The last line of make output would be echoed to the >> console after my prompt returned. >> >> To solve this, I added "&& wait" in each location where the >(...) trick is >> used. I have then rerun the loop over night and could no longer reproduce >> the problem. I believe this to be the proper solution. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8154326 >> Webrev: http://cr.openjdk.java.net/~erikj/8154326/webrev.01/ >> >> /Erik >
