-
-
Notifications
You must be signed in to change notification settings - Fork 287
exec in wrapper script if we aren't in the repl #306
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
Conversation
So I'm not sure I completely understand the problem (haven't used the repl
rule that much) but if we can avoid introducing another conditional by only
generating this output for the repl rule I think it's a win.
What are the downsides?
…On Fri, 13 Oct 2017 at 2:08 P. Oscar Boykin ***@***.***> wrote:
@johnynek <https://github.com/johnynek> requested your review on:
bazel-contrib/rules_scala#306
<#306> exec in wrapper
script if we aren't in the repl.
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
<#306 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABUIF4-oVXbnzw7GEEpu890tROJMAEIhks5srpvqgaJpZM4P3wQ_>
.
|
Actually the java launching script requires the wrapper. I don’t want to refactor the java launching script we have now and I don’t see the gain immediately. The problem we have is that we have tools that kill jobs, but without the exec we don’t kill the underlying process. |
the wrapper script is something in what we are pulling from bazel: |
I agree about not going into a big refactor. Btw, |
the java script from bazel already calls The wrapper script needs to not exec on the repl, since the repl needs to fixup the stty settings. But in the case of other binaries, we want exec (which is how all the java processes work in bazel generally). I don't know what you want exactly. Can you tell me where you want more methods? At the point of creating the wrapper script, I added the exec in a case it is sure to be safe (where there is nothing happening but a call to another program). I will need your help to make it clearer, because it is not unclear to me. (Also note, this is blocking us and causing us to resort to hacks of using sed on the inner scripts generated to manually insert the exec after the fact, which is obviously a bad state to be in. I'd like to get this fixed before we cargo cult this bad sed pattern all over our code and we try very hard to stay on master). |
I meant another method in the bzl file to encapsulate the details of the if and the exec/empty-string If any of this makes sense and you have an idea that's great, otherwise merge it as is. |
Since you say it is okay, I'm going to merge and let us file an issue. I don't really see that the code is cleaner by moving these few lines into a separate function as it is only called once. If you feel more strongly, you are welcome to make an edit that improves things which maybe I don't see right now. |
we had an internal system that didn't work when someone used the
_wrapper
script because we hadn't exec'ed.This fixes it. Really, users should only use the
wrapper.sh
for the repl, but this is probably not clear, so this error is easy to make.Alternatively, we could actually just not generate this file for non-repl targets, which I also think would work although it would be a break for people who have assumed it exists. This seems the most conservative change.actually, the standard launcher calls this wrapper, so I think we do want this PR exactly as is.