[gentoo-dev] new eclass: golang.eclass for compiling go packages

[gentoo-dev] new eclass: golang.eclass for compiling go packages

[William Hubbs]

[-- Attachment #1.1: Type: text/plain, Size: 232 bytes --]

All,

It turns out that we do need a second eclass for Go packages.

this eclass is meant to provide a common src_compile function for
packages written in the Go programming language.

Let me know what you think.

Thanks,

William


[-- Attachment #1.2: golang.eclass --]
[-- Type: text/plain, Size: 1143 bytes --]

# Copyright 1999-2015 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

# @ECLASS: golang.eclass
# @MAINTAINER:
# William Hubbs <williamh@gentoo.org>
# @BLURB: Eclass for compiling go packages.
# @DESCRIPTION:
# This eclass provides a default src_compile function for software
# written in the Go programming language.

case "${EAPI:-0}" in
	5)
		;;
	*)
		die "${ECLASS}: Unsupported eapi (EAPI=${EAPI})"
		;;
esac

EXPORT_FUNCTIONS src_compile

if [[ -z ${_GOLANG} ]]; then

_GOLANG=1

DEPEND=">=dev-lang/go-1.4.2"

# @ECLASS-VARIABLE: EGO_PN
# @REQUIRED
# @DESCRIPTION:
# This is the import path for the go package(s). Please emerge dev-lang/go
# and read "go help importpath" for syntax.
#
# Example:
# @CODE
# EGO_PN="github.com/user/package"
# EGO_PN="github.com/user1/package1 github.com/user2/package2"
# @CODE

golang_src_compile() {
	debug-print-function ${FUNCNAME} "$@"

	[[ -z ${EGO_PN} ]] &&
		die "${ECLASS}: EGO_PN is not set"

	case "$GOPATH" in
		${S}*) ;;
		*) export GOPATH="${S}:${GOPATH}" ;;
	esac

	set -- go build -d -v -work -x "${EGO_PN}"
	echo "$@"
	"$@" || die
}

fi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-dev] new eclass: golang.eclass for compiling go packages

[Andrew Udvare]

> On 2015-06-11, at 08:38, William Hubbs <williamh@gentoo.org> wrote:
> 
> this eclass is meant to provide a common src_compile function for
> packages written in the Go programming language.
> 
> Let me know what you think.
> 

I am wondering about bug 503324 and the issue of needing to create a GOROOT with everything except the package to be compiled. Is your way solving this issue?

My ebuild's src_compile() is based on ones in the tree:

https://github.com/Tatsh/tatsh-overlay/blob/master/dev-go/go-isatty/go-isatty-0_p20150408.ebuild#L31

Andrew

Re: [gentoo-dev] new eclass: golang.eclass for compiling go packages

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1091 bytes --]

On Thu, Jun 11, 2015 at 08:58:37AM -0700, Andrew Udvare wrote:
> 
> > On 2015-06-11, at 08:38, William Hubbs <williamh@gentoo.org> wrote:
> > 
> > this eclass is meant to provide a common src_compile function for
> > packages written in the Go programming language.
> > 
> > Let me know what you think.
> > 
> 
> I am wondering about bug 503324 and the issue of needing to create a GOROOT with everything except the package to be compiled. Is your way solving this issue?

I looked at an example in the tree (specifically go-fuse) and the
src_compile I wrote is the same as the one there.

In the testing I've done here, GOPATH must be set or "go get" doesn't
work. The newest code for packages will always be stored in the first
directory listed in GOPATH, not in GOROOT.

Given how GOPATH works in relation to GOROOT, I don't know yet why the
ebuilds in the tree are copying goroot; I'm not quite sure what they are
working around yet.

For more info, look at "go help gopath" and "go help packages".

Let me know what you think after reading those.

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-dev] new eclass: golang.eclass for compiling go packages

[Zac Medico]

On 06/11/2015 11:43 AM, William Hubbs wrote:
> On Thu, Jun 11, 2015 at 08:58:37AM -0700, Andrew Udvare wrote:
>>
>>> On 2015-06-11, at 08:38, William Hubbs <williamh@gentoo.org> wrote:
>>>
>>> this eclass is meant to provide a common src_compile function for
>>> packages written in the Go programming language.
>>>
>>> Let me know what you think.
>>>
>>
>> I am wondering about bug 503324 and the issue of needing to create a GOROOT with everything except the package to be compiled. Is your way solving this issue?
> 
> I looked at an example in the tree (specifically go-fuse) and the
> src_compile I wrote is the same as the one there.
> 
> In the testing I've done here, GOPATH must be set or "go get" doesn't
> work. The newest code for packages will always be stored in the first
> directory listed in GOPATH, not in GOROOT.
> 
> Given how GOPATH works in relation to GOROOT, I don't know yet why the
> ebuilds in the tree are copying goroot; I'm not quite sure what they are
> working around yet.

For example, dev-go/go-net needs this workaround. Otherwise, if
dev-go/go-net is already installed, it triggers a sandbox violation as
follows:

>>> Compiling source in
/var/tmp/portage/dev-go/go-net-1.4.2_p20150604/work/src/golang.org/x/net ...
WORK=/var/tmp/portage/dev-go/go-net-1.4.2_p20150604/temp/go-build862715022
golang.org/x/net/html/charset
mkdir -p $WORK/golang.org/x/net/html/charset/_obj/
mkdir -p $WORK/golang.org/x/net/html/
cd /usr/lib/go/src/golang.org/x/net/html/charset
/usr/lib/go/pkg/tool/linux_amd64/6g -o
$WORK/golang.org/x/net/html/charset.a -trimpath $WORK -p
golang.org/x/net/html/charset -complete -D
_/usr/lib/go/src/golang.org/x/net/html/charset -I $WORK -pack
./charset.go ./table.go
mkdir -p /usr/lib/go/pkg/linux_amd64/golang.org/x/net/html/
cp $WORK/golang.org/x/net/html/charset.a
/usr/lib/go/pkg/linux_amd64/golang.org/x/net/html/charset.a
go install golang.org/x/net/html/charset: open
/usr/lib/go/pkg/linux_amd64/golang.org/x/net/html/charset.a: permission
denied
-- 
Thanks,
Zac

Re: [gentoo-dev] new eclass: golang.eclass for compiling go packages

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 2899 bytes --]

On Thu, Jun 11, 2015 at 04:39:05PM -0700, Zac Medico wrote:
> On 06/11/2015 11:43 AM, William Hubbs wrote:
> > On Thu, Jun 11, 2015 at 08:58:37AM -0700, Andrew Udvare wrote:
> >>
> >>> On 2015-06-11, at 08:38, William Hubbs <williamh@gentoo.org> wrote:
> >>>
> >>> this eclass is meant to provide a common src_compile function for
> >>> packages written in the Go programming language.
> >>>
> >>> Let me know what you think.
> >>>
> >>
> >> I am wondering about bug 503324 and the issue of needing to create a GOROOT with everything except the package to be compiled. Is your way solving this issue?
> > 
> > I looked at an example in the tree (specifically go-fuse) and the
> > src_compile I wrote is the same as the one there.
> > 
> > In the testing I've done here, GOPATH must be set or "go get" doesn't
> > work. The newest code for packages will always be stored in the first
> > directory listed in GOPATH, not in GOROOT.
> > 
> > Given how GOPATH works in relation to GOROOT, I don't know yet why the
> > ebuilds in the tree are copying goroot; I'm not quite sure what they are
> > working around yet.
> 
> For example, dev-go/go-net needs this workaround. Otherwise, if
> dev-go/go-net is already installed, it triggers a sandbox violation as
> follows:
> 
> >>> Compiling source in
> /var/tmp/portage/dev-go/go-net-1.4.2_p20150604/work/src/golang.org/x/net ...
> WORK=/var/tmp/portage/dev-go/go-net-1.4.2_p20150604/temp/go-build862715022
> golang.org/x/net/html/charset
> mkdir -p $WORK/golang.org/x/net/html/charset/_obj/
> mkdir -p $WORK/golang.org/x/net/html/
> cd /usr/lib/go/src/golang.org/x/net/html/charset
> /usr/lib/go/pkg/tool/linux_amd64/6g -o
> $WORK/golang.org/x/net/html/charset.a -trimpath $WORK -p
> golang.org/x/net/html/charset -complete -D
> _/usr/lib/go/src/golang.org/x/net/html/charset -I $WORK -pack
> ./charset.go ./table.go
> mkdir -p /usr/lib/go/pkg/linux_amd64/golang.org/x/net/html/
> cp $WORK/golang.org/x/net/html/charset.a
> /usr/lib/go/pkg/linux_amd64/golang.org/x/net/html/charset.a
> go install golang.org/x/net/html/charset: open
> /usr/lib/go/pkg/linux_amd64/golang.org/x/net/html/charset.a: permission
> denied

Part of the problem is that golang.org/x/foo repositories try to install
in $GOROOT directly when you try to use "go install"; no other
repositories do this that I'm aware of.

I recommend using "go build" in src_compile to build the things you need
to install, then using manual methods to install the things you want to
install where they need to go.

Also, you can use "go env GOROOT" to get the value of goroot.

Now that i have golang-vcs.eclass in the tree,, I will take a look at
the go-net live ebuild. I will still take a look at reworking this
eclass. When I post it again it will be called golang-build.eclass and
be at the end of this thread.

Thanks,

William

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]