On 07/27/2015 10:12 AM, Vít Ondruch wrote:
Dne 26.7.2015 v 14:03 Jan Chaloupka napsal(a):
On 07/24/2015 03:36 PM, Vít Ondruch wrote:
Dne 9.7.2015 v 11:18 Jan Chaloupka napsal(a):
Recommended use in spec file:
1) To choose the correct compiler:
%ifarch %{golang_arches}
BuildRequires: golang
%else
BuildRequires: gcc-go >= %{gccgo_min_vers}
%endif
2) To choose the correct command for building and testing:
%ifarch %{golang_arches}
%{golang_build} -o bin/binary %{import_path}/binary
%{golang_test} %{import_path}/binary
%else
%{gcc_go_build} -o bin/binary %{import_path}/binary
%{gcc_go_test} %{import_path}/binary
%endif
Why are you not using the %{?golang_arches} and similar (i.e. with the
"?" at the beginning).
Yes, you are right. 0%{?golang_arches} will do better.
This was a heads up. Still needs some polishing.
%ifarch 0%{?gccgo_arches}
BuildRequires: gcc-go >= %{gccgo_min_vers}
%else
BuildRequires: golang
%endif
Why the GO compilers does not provide some
virtual provide, which ensures that the compiler is available, without
even checking for architecture? This would avoid the need of requiring
go-srpm-macros by redhat-rpm-config and it could be build require just
by Go packages.
It is a question of maintainability. Golang does not support ppc64 at
the moment. Supported by gcc-go. In future this can change. Then you
would have to update both golang and gcc components. It means report a
bug on golang and gcc. For gcc this is not a high priority issue. It
would take some time. Plus gcc would have to add ifarch to its spec
file as gcc-go and golang has common architectures.
If you need that change in those packages, it is just one time change
which will happen only once.
And every time golang or gcc-go changes its list of supported architectures.
If you were able to convince RPM maintainer
to introduce this unneeded dependency, I'm pretty sure you can convince
golang/gcc-go maintainers to introduce the virtual provide where it belongs.
go-srpm-macros is one point of change. For virtual provides you would
need at least two. go-srpm-macros is needed anyway otherwise you
duplicate all macros which can get out of sync.
I don't ming go-srpm-macros. That is perfectly fine, if it is BR of
package which needs it. But I don't want to have go-srpm-macros
installed on my system, because I'm quite sure I'm not going to build
any Go package any time soon and hence this is just cruft.
You can say the same about perl-srpm-macros, ocaml-srpm-macros or other
*-srpm-macros package redhat-rpm-config has as a runtime dependency.
go-srpm-macros provides only macros.go-srpm file which takes about 1.1
KB of your memory.
Vít
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
