RFR: JDK-8065576: Enable pipefail in the shell used by make to better detect build errors
pointo1d at gmail.com
Mon Dec 1 16:01:06 UTC 2014
Hiya Erik ,
In every make recipe that I've ever written, I've yet to use the '... run
command ; if test $/; then ...' structure since I always run the shell with
'-e' option enabled and if the command returns a non-zero error status,
then shell picks it up - which explains why the majority of make(1) recipes
that I write utilise a case statement since the case "var in ... does not
return a non-zero error status for the shell to pick up on i.e. the shell
picks up on and fails the recipe if $VAR is unset in the command '... test
"x$$VAR" ...', whereas the same does not hold for the command '... case
"x$$VAR" ...' - the command result is left entirely for the recipe to deal
with as it sees fit.
Best rgds ,
Dave Pointon FIAP MBCS
Now I saw, tho' too late, the folly of beginning a work before we count the
cost and before we we judge rightly of our strength to go thro' with it -
On 1 December 2014 at 13:27, Erik Joelsson <erik.joelsson at oracle.com> wrote:
> New webrev, which addresses Magnus' concern below, and various fixes in
> Hotspot for incompatibilities with errexit.
> Webrev: http://cr.openjdk.java.net/~erikj/8065576/webrev.02/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8065576
> For the LOG=trace issue Magnus described below, it was enough to just
> replace $$(BASH) with $$(SHELL) and things worked as expected for me.
> In Hotspot there were several instances of run command X, followed by "if
> test $? = 0" (or something similar). I changed this to "if X; then" as
> errexit ignores commands that are part of if-statement tests.
> Since this is now touching Hotspot makefiles, it will need to go in
> through a Hotspot group forest.
More information about the build-dev