Packaging golang for secondary architectures, go-srpm-macros

[Jan Chaloupka]

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
>