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.
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.
This is definitely step backward.
Sometimes you have to go back so you can go forward.
Vít
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
