New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix makewrapper unsupported args #25185
Conversation
b867050
to
a6f0fc8
Compare
#24944 depends on this, for the |
Is this a mass rebuild? I'd think so. |
Yes. This PR was split from https://github.com/NixOS/nixpkgs/pull/24944, which might provide more context. Currently, I'm not sure how that will end up. |
@ahmedtd Ok that's cool. I guess I don't know whether the policy is to submit known mass-rebuilds to staging or master. I'd guess staging, as that is where they'd go eventually, but I'm not sure. |
Oh, I thought commits went to staging after passing Hydra on master. Is
there some documentation that lays out which branches are what?
…On Apr 24, 2017 1:08 PM, "John Ericson" ***@***.***> wrote:
@ahmedtd <https://github.com/ahmedtd> Ok that's cool. I guess I don't
know whether the policy is to submit known mass-rebuilds to staging or
master.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#25185 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AA-FcgXlya4m1aCKr67k-3wuuJxuvf9gks5rzOUugaJpZM4NGaZN>
.
|
I'm not sure, but the point of staging is to queue up mass rebuilds so they cancel out a bit for master. There is something about not just merging any old untested thing to staging, but I think that means test locally. This stuff indeed ought to be documented better :). |
Regarding commit policy, see https://nixos.org/nixpkgs/manual/#idm140737318460880 |
I've changed the target branch to staging. |
@@ -32,26 +32,20 @@ makeWrapper() { | |||
for ((n = 2; n < ${#params[*]}; n += 1)); do | |||
p="${params[$n]}" | |||
|
|||
if test "$p" = "--set"; then | |||
if [[ "$p" == "--set" ]]; then |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
wouldn't it make sense to use a switch case here instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A previous PR that did something similar (#19061) ran up against the OSX system version of bash being too old to support the case statement.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fair, the fallthrough is only useful for a single pair of arguments which could be worked around: #19061 (comment)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok Bash 3.2 is not that bad. Or-patterns can be used instead of fall-through (and in fact are a better solution).
# Works in bash 3.2
case n in
p|n) echo yup;;
esac
printf "\n" | ||
|
||
exit 1 | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How does it look like in practice when that happens? Nix's bash is quite convoluted and might have some weird stack trace.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It varies in usefulness, depending on how makeWrapper is being called. Sometimes there's enough information to be helpful, but often the stack trace stops at the point where stdenv/setup.sh
evaluates the current phase hook.
@ahmedtd, this PR has mere conflicts. Would you mind force-pushing an update that is re-based relative to current versions of |
Calling `die "Error message"` causes the current script to exit with an error, printing a backtrace
Previously, makeWrapper would accept arguments it didn't recognize, potentially allowing argument misspellings or broken callers. Now, makeWrapper dies with a backtrace if it is called incorrectly. Also changes `wrapProgram` so that it doesn't pass through the first argument twice --- this was tripping up the argument checking.
a6f0fc8
to
ece5387
Compare
Rebased onto current staging. |
This breaks several packages:
|
While we're at it, if someone could use use |
This looks like preexisting brokenness in nix-prefetch-scripts. I can make
a pr to fix it tonight.
…On Aug 8, 2017 12:16 PM, "John Ericson" ***@***.***> wrote:
While we're at it, if someone could use use case with --suffix-contents |
--prefix-contents) alternatives, per https://github.com/NixOS/
nixpkgs/pull/25185/files#r129576600?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#25185 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AA-FckAFay0fxnA6n3kfL8We81C_-ja_ks5sWLQXgaJpZM4NGaZN>
.
|
staging...obsidiansystems:make-wrapper-clean Here is a draft of that cleanup, if anyone wants to finish it. |
Just a note for a future improvement or someone else that encounters this. The command |
@FRidh That will be a really frustrating experience to debug --- I will send a PR to replace |
@FRidh Would you mind telling me in which file you observed this problem? Both |
Indeed. An example that has scripts in |
Motivation for this change
Previously, makeWrapper would accept arguments it didn't recognize,
potentially allowing argument misspellings or broken callers.
Now, makeWrapper dies with a backtrace if it is called incorrectly.
Also changes
wrapProgram
so that it doesn't pass through the firstargument twice --- this was tripping up the argument checking.
Things done
(nix.useSandbox on NixOS,
or option
build-use-sandbox
innix.conf
on non-NixOS)
nix-shell -p nox --run "nox-review wip"
./result/bin/
)