(Resending as i got a bounce from the list) On 29/09/14 11:04 -0700, Richard Henderson wrote:
I'm working on enabling Go on systems without golang support, but for which the gccgo compiler works. But in order for this to work, there needs to be some amount of coordination with the regular golang package, the spec files of binaries written in go, and the golang-*-devel packages. (0) I start with a "go" driver program that is built with, and defaults to building with, the gccgo compiler. I.e. -compiler gccgo is the default. I've called this package "go-gccgo", for lack of a better name.
cool. DO you have this published somewhere?
(1) I was disappointed to discover that all of the -devel packages depend on golang. That meant that when I wanted to uninstall golang on my test system and install my go-gccgo package, all of the development libraries were uninstalled too. This seems silly, because the -devel packages don't *really* depend on golang, any more than glib2-devel depends on having gcc installed.
This discussion has gone around a bit. Some of the rpms have BuildRequires of 'golang' because they run `go test` in their %check But otherwise, the -devel that is landing source code only, does not require golang. Perhaps we could make this a meta for go API
I think that removing this unnecessary dependency can happen independent of any other change we can make. (2) We need some rpm token to coordinate the version of the Go language that the installed compiler. Currently the packages check "golang >= version", but...
Right, so for go api this is where we should mimic the rpm spec of packages like python or ruby. They need _a_ compiler that can do '>= 1.2' or similar. Make sense?
(3) The golang and go-gccgo packages probably ought to conflict, since both contain a /usr/bin/go. I don't see using alternates as terribly useful here, and anyway there may well be a Go language version conflict from (2) between the two compilers. Certainly for f21, golang is v1.3.1, but gcc 4.9 supports go v1.2.
do that have to conflict? I wouldn't think that is a requirement.
(4) For packages that build binaries written in go, like docker, we need an rpm macro to say whether we expect to build with gccgo or gc. The command line options for the two compilers are not compatible, and so the %build section of the spec file needs to be adjusted (sometimes trivially, sometimes not).
is there precedent of macros like this or is this something we'd need to craft up ourselves?
I'm currently defining %use_gccgo in the /usr/lib/rpm/macros.d/macros.golang file installed with my go-gccgo package. (5) There's currently a %go_arches macro that specifies those arches to which golang is ported. If go-gccgo exists, is this macro actually useful anymore?
I think so, but it may need to be adjusted for the gccgo vs gc macro
Attachment:
pgpS3_kzAt1V_.pgp
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
