On Monday, July 27, 2015 10:12:03 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. 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.
the very nature of the srpm-macros packages precludes the ability of it being
added as a BuildRequire the package defines macros that need to be installed
for srpm creation to set macros and define BuildRequires correctly. any other
macro that is defined belongs elsewhere in a packag that is added as a
BuildRequires.
DennisAttachment:
signature.asc
Description: This is a digitally signed message part.
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
