On 09/29/2014 12:49 PM, Vincent Batts wrote:
> (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?
Not yet. I have an srpm, but some details need to be adjusted with this
discussion. I should probably start the "new fedora package" process though.
>> (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 can certainly understand a BuildRequires.
I could even understand a go-filesystem owning the /usr/share/gocode, and
probably an rpm macros file defining the %gopath variable to match.
I'm not sure what you mean by "a meta for go API".
>> (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?
Yes, that's exactly what I was trying to describe. What should it be called?
>> (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.
Well, I suppose not. There's certainly no point in building go-gccgo on a
target that supports golang, since the regular golang driver has the -compiler
golang option.
We could just ExcludeArch/ExclusiveArch the pair of packages such that only one
exists for a given architecture.
That does open up golang as the "language" token above...
>> (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?
Not that I'm aware of. I think this difference of command line options between
the two compilers is fairly unique.
It's especially nasty wrt -ldflags '-X foo', where the best option I can find
for gccgo looks like
cat >> dockerversion/dockerversion.go <<END
func init() {
IAMSTATIC = true
GITCOMMIT = "$DOCKER_GITCOMMIT"
VERSION = "%{version}"
}
END
in the spec file.
r~
Attachment:
signature.asc
Description: OpenPGP digital signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
