I've discovered what I _think_ is a cygport bug: most functions within cygport run with `set -e` enabled in Bash, so if a command has a non-zero return code that isn't explicitly handled, that'll cause the cygport command overall to fail. This doesn't work within src_install, and I _suspect_ that's a bug following from some decidedly unintuitive Bash behaviour.
The attached test case demonstrates the problem: running `cygport test.cygport prep compile test` will fail, because of the `false` call at the start of `src_test`. Running `cygport test.cygport prep compile install`, however, won't fail, even though there's a `false` call at the start of the `src_install` function. Specifically, when src_install is called in the cygport executable, it's called as below: (__prepinstalldirs && src_install && __src_postinst) 2>&1 | tee -a ${installlog} The fact that Bash normally only considers the final command in a pipeline is handled by a subsequent check of ${PIPESTATUS[0]}, but quoting the Bash man page description for `set -e`: > The shell does not exit if the command that fails is ... part of any > command executed in a && or || list except the command following the > final && or || .... If a compound command other than a subshell > returns a non-zero status because a command failed while -e was being > ignored, the shell does not exit. > > If a compound command or shell function executes in a context where -e > is being ignored, none of the commands executed within the compound > command or function body will be affected by the -e setting, even if > -e is set and a command returns a failure status. So because the function call is part of a && chain, the `set -e` behaviour is completely disabled within that function; the only way a non-zero return code would be propagated from within the function is if (a) it were explicitly `return`ed or (b) it came from the final command in the function. I've provided a single patch to fix this specific issue, partly because I'd already written it and thought I might as well share it, but I think this probably wants a bit more thought. In particular, there are two things that might mean we want to handle this differently: - I've only fixed a single problem, but I think bugs of this style are much more common, e.g. in the similar code for the `cygport compile` command. It might make sense to fix this in far more locations. - I wouldn't be at all surprised if this bug, and others of the same ilk, have become load-bearing. If this gets fixed, it might cause a lot of build scripts that have otherwise been happily ignoring benign non-zero return codes suddenly start failing unexpectedly. Adam Dinwoodie (1): Run install functions separately bin/cygport.in | 26 +++++++++++++++++++------- 1 file changed, 19 insertions(+), 7 deletions(-) -- 2.40.1
NAME=test VERSION=1 RELEASE=1 CATEGORY=Test SUMMARY='Test package' HOMEPAGE= LICENSE= src_compile () { cd "$B" { echo '#!/usr/bin/env sh' echo "echo 'Hello, world!'" } >helloworld } src_install () { false cd "$B" dobin helloworld } src_test () { false PATH="${D}/usr/bin:$PATH" helloworld | grep 'Hello' }