berrange opened a new pull-request against the project: `go-rpm-macros` that you are following: `` Expose Go build flags directly to spec files as a macro ``
To reply, visit the link below or just reply to this email https://pagure.io/go-rpm-macros/pull-request/21
ngompa merged a pull-request against the project: `go-rpm-macros` that you are following.
Merged pull-request:
`` Expose Go build flags directly to spec files as a macro ``
berrange commented on the pull-request: `Expose Go build flags directly to spec files as a macro` that you are following: `` BTW, i just realized my suggested spec file change is not quite right. The original code turned off "pie" for "ppc64", not "ppc64le". ``
To reply, visit the link below or just reply to this email https://pagure.io/go-rpm-macros/pull-request/21
jcajka commented on the pull-request: `Expose Go build flags directly to spec files as a macro` that you are following: `` Yes, the patch snippet should be something like: ``` diff --git a/go-rpm-macros.spec b/go-rpm-macros.spec index 83e02d7..8de41a6 100644 --- a/go-rpm-macros.spec +++ b/go-rpm-macros.spec @@ -7,7 +7,9 @@ Version: 3.0.8 %global _docdir_fmt %{name}
# Master definition that will be written to macro files -%global golang_arches %{ix86} x86_64 %{arm} aarch64 ppc64le s390x +%global golang_pie_arches %{ix86} x86_64 %{arm} aarch64 ppc64le s390x +%global golang_nopie_arches %{nil} +%global golang_arches %{golang_pie_arches} %{golang_nopie_arches} %global gccgo_arches %{mips} # Go sources can contain arch-specific files and our macros will package the # correct files for each architecture. Therefore, move gopath to _libdir and @@ -125,6 +127,12 @@ install -m 0755 -vp rpm/*.{prov,deps} \ %ifarch %{golang_arches} install -m 0644 -vp rpm/macros.d/macros.go-compilers-golang \ %{buildroot}%{_rpmconfigdir}/macros.d/macros.go-compiler-golang +%ifarch %{golang_pie_arches} +rm -f %{buildroot}/%{_rpmconfigdir}/macros.d/macros.go-compilers-golang-nopie +%endif +%ifarch %{golang_nopie_arches} +rm -f %{buildroot}/%{_rpmconfigdir}/macros.d/macros.go-compilers-golang-pie +%endif %endif
%ifarch %{gccgo_arches} ``` ``
To reply, visit the link below or just reply to this email https://pagure.io/go-rpm-macros/pull-request/21
nim commented on the pull-request: `Expose Go build flags directly to spec files as a macro` that you are following: `` @berrange That’s awfully nice, both the runtime ifnarch removal and the generalization to pie/nopie macros
If you think the PR is cooked and @jcajka agrees with it I see no problem in merging it
I probably need to check if the mechanism can be used in go-rpm-macros for tests, having a common way to do things is always good.
Remember that you’re going to lose GOPATH and GO111MODULE assignments, and depending on the Go module weirdness of the day, that may not end well when building within koji. ``
To reply, visit the link below or just reply to this email https://pagure.io/go-rpm-macros/pull-request/21
berrange commented on the pull-request: `Expose Go build flags directly to spec files as a macro` that you are following: `` My only thought for future improvements is to also expose a %gotestflags macro with the equivalent set of flags for testing..... except such a named macro is already in use just setting the compile mode flags right now. I wondered whether you consider that current macro part of the "api promise" or just an internal thing we're able to expand the semantics of ? ``
To reply, visit the link below or just reply to this email https://pagure.io/go-rpm-macros/pull-request/21
jcajka commented on the pull-request: `Expose Go build flags directly to spec files as a macro` that you are following: ``
My only thought for future improvements is to also expose a %gotestflags macro with the equivalent set of flags for testing..... except such a named macro is already in use just setting the compile mode flags right now. I wondered whether you consider that current macro part of the "api promise" or just an internal thing we're able to expand the semantics of ?
This is question for @nim as he is only one whom might know.
Changes LGTM, assuming that the land in to the Fedora will be co-ordinated and announced(if there are any forward of backwards implications) by the maintainers of the respective packages there. ``
To reply, visit the link below or just reply to this email https://pagure.io/go-rpm-macros/pull-request/21
rishi commented on the pull-request: `Expose Go build flags directly to spec files as a macro` that you are following: `` Could we please have a new `go-rpm-macros` build in Fedora that includes `%gobuildflags` (with the corresponding RPM spec changes discussed here)?
We have Go code in [toolbox](https://github.com/containers/toolbox) that's built using Meson, and would really benefit from this. ``
To reply, visit the link below or just reply to this email https://pagure.io/go-rpm-macros/pull-request/21
rishi commented on the pull-request: `Expose Go build flags directly to spec files as a macro` that you are following: `` Ping ``
To reply, visit the link below or just reply to this email https://pagure.io/go-rpm-macros/pull-request/21
rishi commented on the pull-request: `Expose Go build flags directly to spec files as a macro` that you are following: `` Yay! We have 3.0.9 now. Thank you. ``
To reply, visit the link below or just reply to this email https://pagure.io/go-rpm-macros/pull-request/21
rishi commented on the pull-request: `Expose Go build flags directly to spec files as a macro` that you are following: `` The RPM spec file changes slipped through the cracks. I filed: https://src.fedoraproject.org/rpms/go-rpm-macros/pull-request/1 ``
To reply, visit the link below or just reply to this email https://pagure.io/go-rpm-macros/pull-request/21
golang@lists.fedoraproject.org
-
Daniel P. Berrange -
Debarshi Ray
-
Jakub Čajka
-
Neal Gompa
-
Nicolas Mailhot