Re: [RFC] Go (golang) packaging
Hi Simon,
Simon McVittie <smcv@debian.org> writes:
> Where does gccgo look for Go sources (src)?
> Where does gccgo look for Go "static libraries" (pkg)?
> Where does gccgo look for Go dynamic libraries? (Presumably the same
> places where gcc looks for C dynamic libraries?)
I can’t really answer these questions in depth, but the way I usually
invoke it is by using go(1)’s -compiler option, in which case the lookup
works the same as with the “original” go compiler.
I’m not sure whether Debian should support gccgo at all. Will ask the Go
mailing lists on what they think.
> Michael additionally wrote:
>> I propose to patch
>> Go in Debian so that it always appends /usr/lib/gocode when reading
>> the list of paths from $GOPATH.
>
> Add /usr/local/lib/[$TUPLE/]gocode as "more important than"
> /usr/lib/[$TUPLE/]gocode, perhaps? That's how /usr/local usually works
> in Debian.
Mentioning /usr/local is a good point, but I’m not sure whether it’s
really a good idea: in the Go community, setting $GOPATH to a directory
within your home directory (e.g. ~/gocode) is normal and what everyone
uses. To install a third-party library, you just “go get” its URL, e.g.
go get code.google.com/p/codesearch
Which will then download the library to
~/gocode/src/code.google.com/p/codesearch.
Nobody will have libraries in /usr/local, because there is no facility
(no Makefiles) to install them there. The local directory is rather
specified by the user in $GOPATH — that is the idiomatic way.
> For multi-arch headers and development libraries (not formally in-scope
> for wheezy, but some simpler packages already support it, and it's
> likely to be a goal for jessie), it's useful to be multiarch so an
> i386/amd64 system can have both golang-libhello:amd64 and
> golang-libhello:i386, so that it can build both helloworld:amd64 and
> helloworld:i386.
You cannot currently cross-compile an i386 binary on an amd64 host with
the Go packages we have in Debian. I consider this a separate issue.
Essentially, when we have a golang-go package that contains a version of
the compiler which has been built to support cross-compiling for a
particular architecture (say golang-go-i386), you can cross-compile
using the source code of the libraries, a pre-compiled version is not
necessary.
To state this clearly: The benefit of shipping the pkg/ files in Debian
packages at all is to avoid re-compilation every time the user builds
code that depends on the library. We could just as well leave out the
pkg/ files and everything would still work — just slower.
> Should the package with the "headers" and "static library" be
> golang-codesearch-dev or something, in the hope that when Go grows the
> ability to build dynamic libraries, the dynamic libraries can be called
> golang-codesearch?
Yeah, I suppose we should name them -dev. AFAICT, there is some movement
into the shared library direction, see
https://groups.google.com/d/msg/golang-nuts/VS-Pt38097Q/MXMRFc7G26IJ
https://codereview.appspot.com/6926049/
> How "cheap" is recompiling everything? If it's sufficiently cheap, you
> could just ship complete source and ignore the "static libraries"
> entirely; or if it isn't, you'll benefit from proper multiarch.
See above. We could ship without the static libraries, but having them
speeds up compilation noticably in big projects.
--
Best regards,
Michael
Reply to: