linkdupont opened a new pull-request against the project: `go-rpm-macros` that you are following: `` fix(macros): use gobuildflags macro in %gobuild ``
To reply, visit the link below or just reply to this email https://pagure.io/go-rpm-macros/pull-request/35
ngompa commented on the pull-request: `fix(macros): use gobuildflags macro in %gobuild` that you are following: `` Can you please change this to `GOBUILDTAGS`? ``
To reply, visit the link below or just reply to this email https://pagure.io/go-rpm-macros/pull-request/35
linkdupont commented on the pull-request: `fix(macros): use gobuildflags macro in %gobuild` that you are following: `` I'm dodging that issue and just cleaning up the DRY violation part. :stuck_out_tongue_closed_eyes: But seriously, I'm not sure where I stand on that. If we were to change it to `GOBUILDTAGS`, are we certain there aren't existing spec files that don't already make use of the existing `BUILDTAGS` variable? I think I agree it should be called `GOBUILDTAGS` because they are build tags explicitly for the Go compiler. But I want to look through existing specs to understand what kind of a breaking change (if any) that rename would cause. ``
To reply, visit the link below or just reply to this email https://pagure.io/go-rpm-macros/pull-request/35
ngompa commented on the pull-request: `fix(macros): use gobuildflags macro in %gobuild` that you are following: `` Sure, Let's figure that out and make it happen soon though. Frankly, I want these macros to make more sense... ``
To reply, visit the link below or just reply to this email https://pagure.io/go-rpm-macros/pull-request/35
ngompa commented on the pull-request: `fix(macros): use gobuildflags macro in %gobuild` that you are following: `` :thumbsup: ``
To reply, visit the link below or just reply to this email https://pagure.io/go-rpm-macros/pull-request/35
ngompa merged a pull-request against the project: `go-rpm-macros` that you are following.
Merged pull-request:
`` fix(macros): use gobuildflags macro in %gobuild ``
linkdupont commented on the pull-request: `fix(macros): use gobuildflags macro in %gobuild` that you are following: `` I think this helps to normalize the macros by removing redundancy. I'd like to figure out the LDFLAGS use too though. It looks like the macro is assuming LDFLAGS to mean Go compiler LDFLAGS. Which seems reasonable in the context of a Go spec file. So does that mean that the macro can also assume that `BUILDTAGS` means Go compiler BUILDTAGS, because it's in the context of a Go spec file? There /is/ already a way to define external linker flags by setting `__golang_extldflags` to a value in the spec file (not sure I agree with *that* name either, but there it is...), so I _believe_ it is safe to assume that `LDFLAGS` means "pass these values to the Go compiler's `-ldflags` flag. ``
To reply, visit the link below or just reply to this email https://pagure.io/go-rpm-macros/pull-request/35
linkdupont commented on the pull-request: `fix(macros): use gobuildflags macro in %gobuild` that you are following: ``
Sure, Let's figure that out and make it happen soon though. Frankly, I want these macros to make more sense...
For the record, at the current time, the following spec files use `BUILDTAGS` in some capacity.
``` buildah.spec go-compilers.spec golang-github-prometheus.spec hugo.spec grafana.spec moby-engine.spec weldr-client.spec golang-github-prometheus-node-exporter.spec oci-seccomp-bpf-hook.spec cri-tools.spec stargz-snapshotter.spec podman.spec snapd.spec runc.spec syncthing.spec source-to-image.spec skopeo.spec reg.spec pack.spec ``` ``
To reply, visit the link below or just reply to this email https://pagure.io/go-rpm-macros/pull-request/35
golang@lists.fedoraproject.org
-
Link Dupont -
Neal Gompa