On 2016-04-22 10:12, Magnus Ihse Bursie wrote:
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?
That's an interesting idea, but also a source of complications. Say we
add a valid configure setting that doesn't actually compile anything
native (just for running tests for example), do we then require a native
toolchain anyway just to create this binary?
/Erik
/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
