Re: Ability to specify compiler package for Go build system.

On Wed, Jan 11, 2023 at 08:02:15PM -0500, Leo Famulari wrote: > That's correct. You can put something like this in the package > arguments: > > #:go ,go-1.19 This was undocumented... sorry! I just rectified that in commit 9ec62d1b9c55104f9ab81b95d82988c627a23415.

Re: Ability to specify compiler package for Go build system.

On Wed, Jan 11, 2023 at 05:25:18PM +, ( wrote: > Pretty sure there *is* already a #:go argument, but I might be misremembering. That's correct. You can put something like this in the package arguments: #:go ,go-1.19

Re: Ability to specify compiler package for Go build system.

> Pretty sure there is already a #:go argument, but I might be misremembering. Just took a look in the build-system and I can't find that argument. Maybe I didn't search correctly anyway... :) Cheers!

Re: Ability to specify compiler package for Go build system.

On Wed Jan 11, 2023 at 1:49 AM GMT, Hilton Chain wrote: > Though it's possible to package the last version supports Go 1.17 (v1.38.0), > I wonder if we can > adjust the build system so that a Go package could be specified via an > argument in the package > definition. Pretty sure there *is*

Re: Ability to specify compiler package for Go build system.

Hilton Chain writes: > Hi Guix, > > I'm trying to package wakatime-cli[1], while Guix uses Go 1.17 as the > default, the package requires Go 1.19 at the current version > (v1.60.4). > > Though it's possible to package the last version supports Go 1.17 > (v1.38.0), I wonder if we can adjust the

Re: Ability to specify compiler package for Go build system.

adjust the build system so that a Go package could be specified via an > argument in the package > definition. > > Thanks! > > [1] https://github.com/wakatime/wakatime-cli I don't know if that's the case for the Go build system but in the gnu build system adding the compiler

Ability to specify compiler package for Go build system.

Hi Guix, I'm trying to package wakatime-cli[1], while Guix uses Go 1.17 as the default, the package requires Go 1.19 at the current version (v1.60.4). Though it's possible to package the last version supports Go 1.17 (v1.38.0), I wonder if we can adjust the build system so that a Go package

Re: go-build-system possible improvments

Hi François, François writes: > Hello Maxim, > > On Tue, Apr 20, 2021 at 10:00:15PM -0400, Maxim Cournoyer wrote: >> That's exactly what we're doing now (disable Go module with >> GO11MODULE=off and use GOPATH to find the sources). Debian does >> something lazy like just calling 'go module

Re: go-build-system possible improvments

Hello Maxim, On Tue, Apr 20, 2021 at 10:00:15PM -0400, Maxim Cournoyer wrote: > That's exactly what we're doing now (disable Go module with > GO11MODULE=off and use GOPATH to find the sources). Debian does > something lazy like just calling 'go module vendor', which builds a huge > directory

Re: go-build-system possible improvments

dn't know that. My high level idea was to mimic GOPATH but with GOPROXY; instead of source files, we'd have the metadata + zip (sources) populated in a given directory (say, the gocache/ subdirectory) of every Go package in Guix, and then could build a union of these various directories in

go-build-system possible improvments

Hello, I come back to public guix-devel as I think it can be of interest to others too. On Sat, Apr 17, 2021 at 08:57:03PM -0400, Maxim Cournoyer wrote: > JOULAUD François writes: > > > I am still unsure of what to do with versions and Go but the ability to > > pin version will surely be useful

Re: 03/03: build: go-build-system: Ensure uniform unpacking directory.

is change makes it so >> that >> whether the type of the source, it is unpacked at the expected location >> given >> by the IMPORT-PATH of the Go build system. >> >> * guix/build/go-build-system.scm: Add the (ice-9 ftw) module. >> (unpack): Add inn

Re: 02/03: build: go-build-system: Use WHEN for side-effect conditionals.

Hi Mark, Mark H Weaver writes: > Hi Maxim, > > guix-comm...@gnu.org writes: > >> apteryx pushed a commit to branch master >> in repository guix. >> >> commit 7e84d3eef724ef18f8e1c1b0932b6f74d3ae3e35 >> Author: Maxim Cournoyer >> Date: Thu Apr

Re: 03/03: build: go-build-system: Ensure uniform unpacking directory.

Hello again, guix-comm...@gnu.org writes: > apteryx pushed a commit to branch master > in repository guix. > > commit f42e4ebb56fe4f16991ca6c6e060c8f3535865cb > Author: Maxim Cournoyer > Date: Fri Apr 5 00:00:08 2019 -0400 > > build: go-build-system: Ensure uni

Re: 02/03: build: go-build-system: Use WHEN for side-effect conditionals.

Hi Maxim, guix-comm...@gnu.org writes: > apteryx pushed a commit to branch master > in repository guix. > > commit 7e84d3eef724ef18f8e1c1b0932b6f74d3ae3e35 > Author: Maxim Cournoyer > Date: Thu Apr 4 23:26:04 2019 -0400 > > build: go-build-system: Use WHEN for

Re: Go build system updates and future work?

On Fri, Mar 15, 2019 at 09:40:15PM -0500, Katherine Cox-Buday wrote: > There is a larger change coming that I think we need to account for. Go > modules are here (and in v1.13 will be on by default). This feature > allows Go code to be built outside of a $GOPATH. I'm unsure how this > information

Re: Go build system updates and future work?

Pierre Neidhardt skrev: (15 mars 2019 07:54:49 CET) >What about adding and extra key #:test-directories that takes a list of >directories where we would "cd && go test"? > >-- >Pierre Neidhardt >https://ambrevar.xyz/ +1 -- Sent from my k-9 mail for Android.

Re: Go build system updates and future work?

Leo Famulari writes: > On Thu, Mar 14, 2019 at 11:54:30PM +0100, Pierre Neidhardt wrote: >> Erratum: You've packaged go-github-com-kr-text a second time :p > > Oops! Fixed in 10b30b97735ba9037f4ce58867f47678d78f4970 > >> This has happened to me once. I think we should have a linter to protect

Re: Go build system updates and future work?

Leo Famulari writes: > I just pushed a revamped Go build system with commit > e3900a4d64e4bf6f426809d6bff058e5a2ae9bc8. > > The main change is that instead of putting the list of Go-language > dependencies store paths in the GOPATH environment variable, these store > paths a

Re: Go build system updates and future work?

On Thu, Mar 14, 2019 at 11:51:06PM +0100, Pierre Neidhardt wrote: > Agreed! This should also make the Go importer more trivial to write/finish! Okay, I'll try it. The only part I'm not sure about is what to "build" or "test" for these library collections. Currently many of them run test suites,

Re: Go build system updates and future work?

On Thu, Mar 14, 2019 at 11:54:30PM +0100, Pierre Neidhardt wrote: > Erratum: You've packaged go-github-com-kr-text a second time :p Oops! Fixed in 10b30b97735ba9037f4ce58867f47678d78f4970 > This has happened to me once. I think we should have a linter to protect > against this. Thoughts? I

Go build system updates and future work?

I just pushed a revamped Go build system with commit e3900a4d64e4bf6f426809d6bff058e5a2ae9bc8. The main change is that instead of putting the list of Go-language dependencies store paths in the GOPATH environment variable, these store paths are union-symlinked into the build directory, and GOPATH

Re: [go-build-system]

On Thu, Aug 31, 2017 at 08:17:15AM -0400, Leo Famulari wrote: > I have a work-in-progress of a go-build-system with packages for > Syncthing up here: > > https://github.com/lfam/guix/tree/wip-syncthing > > It seems to work until the Syncthing build fails like this: I'm *ver

Re: [go-build-system] How to access properties or keys of a package on the build side?

Leo Famulari writes: > On Mon, Aug 28, 2017 at 10:32:41PM +0200, Ricardo Wurmus wrote: >> >> Ricardo Wurmus writes: >> >> > You could also access the arguments of another package with >> > “package-arguments”. Using the “properties” field isn’t pretty

Re: [go-build-system] How to access properties or keys of a package on the build side?

On Mon, Aug 28, 2017 at 10:32:41PM +0200, Ricardo Wurmus wrote: > > Ricardo Wurmus writes: > > > You could also access the arguments of another package with > > “package-arguments”. Using the “properties” field isn’t pretty because > > it is a free form alist. > > > > You

Re: [go-build-system]

On Tue, Aug 29, 2017 at 03:54:40PM +0300, Frederick Muriithi wrote: > Maybe the following will help clarify the issue: > > The package being built needs the sources of the dependenc(y/ies) to > be available in its GOPATH. > > The build system needs to set the GOPATH such that t

Re: [go-build-system] How to access properties or keys of a package on the build side?

On Mon, Aug 28, 2017 at 10:32:41PM +0200, Ricardo Wurmus wrote: > > Ricardo Wurmus writes: > > > You could also access the arguments of another package with > > “package-arguments”. Using the “properties” field isn’t pretty because > > it is a free form alist. > > > > You

[go-build-system] How to access properties or keys of a package on the build side?

Maybe the following will help clarify the issue: The package being built needs the sources of the dependenc(y/ies) to be available in its GOPATH. The build system needs to set the GOPATH such that the Go build system will find the the dependencies and build against them. I have a repository[1

Re: [go-build-system] How to access properties or keys of a package on the build side?

Ricardo Wurmus writes: > You could also access the arguments of another package with > “package-arguments”. Using the “properties” field isn’t pretty because > it is a free form alist. > > You can use “find-tail” to jump to the keyword in “arguments” and then > pick the

Re: [go-build-system] How to access properties or keys of a package on the build side?

Leo Famulari <l...@famulari.name> writes: > So, a Go build system needs to somehow create a symlink union of the > dependency graph, making the dependencies available at the correct paths > relative to the root of the build environment. AFAICT, we can't figure > these paths o

[go-build-system] How to access properties or keys of a package on the build side?

Recently I made some progress on finishing the prototype go-build-system from Petter [0], and I need some advice. AFAICT, building a Go program requires the program's Go dependencies to have a particular filesystem layout, which corresponds to the way these dependencies are imported

Re: Syncthing and Go Build System

ith, so it's understandable that there aren't any go projects in > guix. > > Has there been any progress with this? Recently I dove in to that prototype of the go-build-system, which does build a working Syncthing package. The prototype illustrates what is required for the go-build-system, al

Syncthing and Go Build System

I saw some posts back in December about adding syncthing to guix, but they stopped in January with no noticeable result. I'd like to see syncthing in guix, although I have an idea of how difficult go is to deal with, so it's understandable that there aren't any go projects in guix. Has there

Re: gnu: Add Go build system.

ource has changed, and how that works on Guix. Optimizations could be made for sure, I will look at this at convenience. On 2016-12-16 05:49, Leo Famulari wrote: On Sun, Dec 11, 2016 at 01:17:48AM +0100, Petter wrote: From 4c0597a95ae3cd111ef12d675edf501c559458ba Mon Sep 17 00:00:00 2001 From: Petter &

Re: gnu: Add Go build system.

On Sun, Dec 11, 2016 at 01:17:48AM +0100, Petter wrote: > From 4c0597a95ae3cd111ef12d675edf501c559458ba Mon Sep 17 00:00:00 2001 > From: Petter <pet...@mykolab.ch> > Date: Sun, 11 Dec 2016 01:10:09 +0100 > Subject: [PATCH] gnu: Add Go build system. > > * guix/build

Re: gnu: Add Go build system.

bad and there's a > lot to do make it ok-ish. That's where you come in :) I haven't contributed or carefully studied the other build systems yet, so my feedback will be rather superficial. I hope somebody with some more knowledge will jump in :) > Subject: [PATCH] gnu: Add Go build sy

gnu: Add Go build system.

, and its dependencies in a later e-mail. These recipes uses this Go build system, and my primary goal has been to make these nice, while functional. Now we can hopefully work on the build system with a minimum of modifications to the recipes. Happy hacking! PetterFrom

Re: remove patchworks. [notes on gitlab, go-build-system, ruby]

t; Ludo’. > I Agree. Regarding gitlab: if we do not want the omnibus package (we will not be able to use this easily on guixsd anyway), we need at least a go-build-system. I have outlined most of what I need to achieve what I want from GuixSD[0], and go-build-system based packages and items are n

go-build-system

Yet another "sidequest" because I keep running into walls with everything: I've started working on Gogs which requires so many go dependencies[0] that I started working on a Go build-system. The resulting packages which will use the go-build-system I would move into gnu/packages/golang

Re: Go build system

On Tue, Jul 26, 2016 at 07:33:25AM +0100, Christopher Baines wrote: > On 25/07/16 20:50, Leo Famulari wrote: > > https://anonscm.debian.org/git/pkg-go/packages/syncthing.git/tree/debian/rules#n42 > > Just in case you are trying to understand the Debian package, be aware > that some files are

Re: Go build system

On 25/07/16 20:50, Leo Famulari wrote: > I don't fully understand Debian's packaging, but it seems that they only > use external packages to provide 2 of 39 dependencies, bootstrap and > font-awesome: > https://anonscm.debian.org/git/pkg-go/packages/syncthing.git/tree/debian/rules#n42 Just in

Re: Go build system

On Mon, Jul 25, 2016 at 12:25:40AM +0200, Ludovic Courtès wrote: > It outlines the command sequence that needs to be run. I’d suggest > starting from that in ‘go-build-system’. Let’s make it work for this > package, and then we can adjust if some of the assumptions happened to >

Re: Go build system

On Mon 25 Jul 2016 00:25, l...@gnu.org (Ludovic Courtès) writes: >> Should Go packages refer to the compiler? This Syncthing package does >> retain a reference. > > I suppose it keeps a reference to run-time support libraries provided by > the ‘go’ package? I believe that unless you specifically

Re: Go build system

hat needs to be run. I’d suggest starting from that in ‘go-build-system’. Let’s make it work for this package, and then we can adjust if some of the assumptions happened to be specific to Syncthing. > Should Go packages refer to the compiler? This Syncthing package does > retain a reference. I s

Go build system

Now that we have go-1.4 and (almost) go-1.5, we should start thinking about a go-build-system. I just wrote my first package using Go, the crude Syncthing package that is attached. It still needs a lot of work, especially since it builds Syncthing's dependencies from bundled copies instead

Re: Is anybody working on a go build system in guix?

On Sat, Feb 27, 2016 at 09:12:42PM +0200, Efraim Flashner wrote: > On Fri, 26 Feb 2016 16:36:56 -0500 > Leo Famulari wrote: > > > On Fri, Feb 26, 2016 at 03:59:49PM -0500, Thompson, David wrote: > > > On Fri, Feb 26, 2016 at 2:31 PM, wrote: > > > >

Re: Is anybody working on a go build system in guix?

On Fri, 26 Feb 2016 16:36:56 -0500 Leo Famulari wrote: > On Fri, Feb 26, 2016 at 03:59:49PM -0500, Thompson, David wrote: > > On Fri, Feb 26, 2016 at 2:31 PM, wrote: > > > I have lately looked closer at IPFS and I would like to compile and run it >

Re: Is anybody working on a go build system in guix?

On Fri, Feb 26, 2016 at 03:59:49PM -0500, Thompson, David wrote: > On Fri, Feb 26, 2016 at 2:31 PM, wrote: > > I have lately looked closer at IPFS and I would like to compile and run it > > on GuixSD but don't know how to succeed without a build system. > > We would need

Re: Is anybody working on a go build system in guix?

On Fri, Feb 26, 2016 at 2:31 PM, wrote: > I have lately looked closer at IPFS and I would like to compile and run it > on GuixSD but don't know how to succeed without a build system. We would need a Go toolchain first. I recall at least two people trying to package Go

Is anybody working on a go build system in guix?

I have lately looked closer at IPFS and I would like to compile and run it on GuixSD but don't know how to succeed without a build system. cheers sdb