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
cmd/go: escape quoted strings in GOFLAGS #26849
Comments
@bcmills if you want to support cmd.exe users on Windows, you should consider how quoting works in cmd.exe. For example, this http://daviddeley.com/autohotkey/parameters/parameters.htm#WINCMDRULES shows cmd.exe rules. Alex |
Sorry, but no. I looked at this when I added GOFLAGS, and we don't do any special quoting for the other environment variables ( This means you cant use GOFLAGS for your example. |
My usage of I think Respectfully, I would request that this be reopened and reconsidered, especially since the primary use case where this feature got me excited (building the same binary for a load of different architectures in a row) aren't actually helped by this feature today. (I commented on the CL and was redirected here. |
@rsc I'm not sure I understand the argument for not permitting quoting in the environment variable given the special support we have for quoting in -gcflags and friends. It seems to me that there are clear uses for passing multiple options to all builds, such as the |
Leaving for Go 1.13. GOFLAGS is relatively new and the workaround is to use the command line, like you had to do before Go 1.11. |
In case we do loosen this constraint on At the moment the last
Given my use-case, this is relatively easy to work around by parsing the space-separated But if we allow escape quoted strings in I suspect allowing multiple instances of |
Also note that the per-package flags like Not saying that I disagree with allowing multiple |
Re-reading what I wrote in #26849 (comment) I realise it wasn't that clear. At the moment, because
it can't contain a multi-value
Add to that, Hence at the moment, it is not possible to specify a multi-value For my specific case there are at least two possible non-mutually exclusive solutions:
It is for this second option that I can create a separate issue if required. |
Another alternative that would only work for |
Change https://golang.org/cl/173438 mentions this issue: |
Funnily enough, I thought that was how |
Using commas makes it possible to put multiple tags into GOFLAGS. The space-separated form is still recognized and will be maintained. Alleviates #26849 somewhat. Fixes #18800 (again). Change-Id: I6f4cf28ea31e53e21ccbdad6ef1a0aee63b007d7 Reviewed-on: https://go-review.googlesource.com/c/go/+/173438 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Ian Cottrell <iancottrell@google.com>
* Stub out MP4 loader for production builds. * Change alohacam `Makefile` to use a `buildcmd` function instead of a constant `BUILDCMD`. This is necessary because we want to specify *two* build tags (`production` and `v4l2`), but `GOFLAGS` does not allow setting multiple tags. (This should be fixed in 1.13, which is imminent. See golang/go#26849.)
* Stub out MP4 loader for production builds. * Change alohacam `Makefile` to use a `buildcmd` function instead of a constant `BUILDCMD`. This is necessary because we want to specify *two* build tags (`production` and `v4l2`), but `GOFLAGS` does not allow setting multiple tags. (This should be fixed in 1.13, which is imminent. See golang/go#26849.)
Don't mean to bump the thread, but - is this planned for 1.14, or is it likely to be moved to 1.15 if noone works on it? If so, I really want a fix for this problem, so I can work on a fix for 1.14. We'd just need to agree on either of these solutions:
I personally think option 2 is the most consistent, and probably the simplest. Like with |
But IIUC it doesn't work once you specify more than one flag to
Personally, I don't find the statement "we don't do any special quoting for the other environment variables" to be a compelling reason not to strive for this invariant as it disregards a sensible request based on a present technical limitation. A better response might be "treating specific environment variables differently will increase the maintenance burden beyond what we're happy with given our CLI architecture." Perhaps due to cross-platform considerations. I still don't find it compelling, but I'd understand. In support of this as a use case, take this example:
I specifically want to use GOFLAGS to achieve the same thing, because I want to use
This doesn't work, as |
#29096 was de-duped into this bug, so I’m posting here, but please let me know if I should open a separate issue for this: Comment #26849 (comment) already touches upon the override semantics issue ( For my use-case, I want to set the ELF interpreter in my build system, so I figured I’d set the
This works in general, but breaks as soon as the software in question specifies its own ldflags on the command line, like e.g. containerd does in its Makefile. It’s easy to verify this:
Notably, from C build systems, I’m used to LDFLAGS generally being extended, never overridden. For my use-case, I’m currently setting |
@stapelberg I think you raise a valid point, and I've thought about it as well, but I think that should be filed as a separate issue. That is, when @myitcv already mentioned raising this issue separately in #26849 (comment) for |
I didn't get much of a response on #26849 (comment) aside form a couple of reactions, so I didn't feel like there was enough consensus to try something out for 1.14. This 1.15 cycle is being weird, but I'd like to give this a try in the two remaining weeks. @bcmills do you still prefer adding simple quoting support to @ianthehat do you still prefer adding support for flags like I used to prefer the second option, but I'm starting to think that simple quoting support is a better long-term fix. Commas are really only a short-term fix, don't support nesting of list parameters which also use commas, and IMO make complex list flags like So, I now propose that we add support for two quoting syntaxes on all platforms equally:
These should be fairly easy to implement. For example, the second would reuse https://golang.org/pkg/strconv/#Unquote for unquoting. If this generally seems like a good idea, I can send a CL this coming week and we can give it a try during the freeze. |
Filed #38522. Please amend as you see fit. |
This commit removes the DWARF debugging information[1] Decided not to try to also turn off generation of the Go symbol table using the `-s` flag, as: 1. the GOFLAGS functionality currently only allows 1 ldflag to be set[2] (NB this may be fixed in Go 1.15[3]) 2. The improvements to the binary size in Go 1.15 [4] mean that the `-s` flag will no longer really do anything[5] Will also try shrinking the binary size further using upx[6] in a separate pull request. [1] https://stackoverflow.com/a/22276273 [2] golang/go#38522 [3] golang/go#26849 (comment) [4] See #64 [5] https://twitter.com/bradfitz/status/1256989624590712834 [6] https://upx.github.io/
This commit removes the DWARF debugging information[1], resulting in the Docker image size shrinking from 4.76MB to 2.88MB. Decided not to try to also turn off generation of the Go symbol table using the `-s` flag, as: 1. the GOFLAGS functionality currently only allows 1 ldflag to be set[2] (NB this may be fixed in Go 1.15[3]) 2. The improvements to the binary size in Go 1.15 [4] mean that the `-s` flag will no longer really do anything[5] Will also try shrinking the binary size further using upx[6] in a separate pull request. [1] https://stackoverflow.com/a/22276273 [2] golang/go#38522 [3] golang/go#26849 (comment) [4] See #64 [5] https://twitter.com/bradfitz/status/1256989624590712834 [6] https://upx.github.io/
This commit removes the DWARF debugging information[1], resulting in the Docker image size shrinking from 4.76MB to 2.88MB. Decided not to try to also turn off generation of the Go symbol table using the `-s` flag, as: 1. the GOFLAGS functionality currently only allows 1 ldflag to be set[2] (NB this may be fixed in Go 1.15[3]) 2. The improvements to the binary size in Go 1.15 [4] mean that the `-s` flag will no longer really do anything[5] Will also try shrinking the binary size further using upx[6] in a separate pull request. [1] https://stackoverflow.com/a/22276273 [2] golang/go#38522 [3] golang/go#26849 (comment) [4] See #64 [5] https://twitter.com/bradfitz/status/1256989624590712834 [6] https://upx.github.io/
Just hit this while trying to make a Specific problems encountered:
My conclusion so far is that making Go more pleasant to use in non-trivial build environments is not possible with GOFLAGS, and painfully difficult without. Neither is a happy outcome, and makes it harder to use a mostly-plain EDIT: sorry, minor correction. Looking at the source code of the |
This requires moving ldflags from goflags to the cmdline because of golang/go#26849
This requires moving ldflags from goflags to the cmdline because of golang/go#26849
In https://golang.org/cl/126656, @rsc added the
GOFLAGS
environment variable.The variable is space-separated, but it is sometimes useful to include spaces within flags passed to the go command (for example, as the final argument to
list -f
). It would be nice to recognize at least a subset of the usual quoting conventions when parsingGOFLAGS
.The text was updated successfully, but these errors were encountered: