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. 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.
Vít
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
