linkdupont commented on the pull-request: `Add BUILDTAGS to %gobuildflags` that you are following: ``
+1 to `GOBUILDTAGS`. The macros already make use of `GOBUILDFLAGS`, so this follows convention. It also avoids the (albeit narrow) situation where `BUILDTAGS` is already assumed to mean "C build tags" and a spec file is attempting to modify both CGo build configurations and Go build configurations. It's trivial to adjust existing spec files to use `GOBUILDTAGS` instead of `BUILDTAGS`.
I think I might be changing my opinion on this. Looking at the macros again, internally, they look for variables such as `BUILDTAGS` and `LDFLAGS`[1]. The `GOBUILDFLAGS` mention only actually occurs in a comment, proposing an example usage of declaring a `make` or `autoconf` variable called `GOBUILDFLAGS` (the assumption being that the Makefile or configure.ac is looking for the variable `GOBUILDFLAGS` in order to pass it to a call to the compiler directly). The `%gobuildflags` macro and the `%gobuild` macro both look for `LDFLAGS` internally to expand the value it passed to the `-ldflags` option. Therefore, updating the `%gobuildflags` macro to use `BUILDTAGS`, just like the `%gobuild` macro is already doing, makes a lot of sense.
1: https://pagure.io/go-rpm-macros/blob/master/f/rpm/macros.d/macros.go-compile... ``
To reply, visit the link below or just reply to this email https://pagure.io/go-rpm-macros/pull-request/34