guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#34613] Acknowledgement ([PATCH] gnu: Add prometheus.)


From: Pierre Neidhardt
Subject: [bug#34613] Acknowledgement ([PATCH] gnu: Add prometheus.)
Date: Tue, 12 Mar 2019 08:03:55 +0100
User-agent: mu4e 1.0; emacs 26.1

> > (Should we package the stuff there, and link the sources into the tree?)
>
> I think we generally do that yes.  Pierre, Leo?

We used to, but since Go 1.10 there is a bug in the compiler which keeps tracks
of _all_ recursive dependencies in the resulting _static_ binary.  This can
result in a ridiculously large closure size.

As for now, I'd recommend the following:

- If there are many dependencies (check the vendor/ folder), use it, it will be
  easier and produce a package with an ideal closure size.

- If it's only a few dependencies, it's probably worth it to package all of them
  independently.

> > I am willing to do the work, but I need some pointer, as I am not into go.
>
> I’m ignorant about Go, but hopefully Pierre, Leo, or someone else with
> experience with Go packaging can provide some guidance!

For a Go package with unvendored deps, I suggest you look at "demlo", it's
reasonably easy to understand.  For vendored deps, look at go-ipfs.

The Go build system does most things right.  A few pointers:

- Prometheus might use its own build system, e.g. with a Makefile.  Then you'll
  have to read the makefile to know what it's doing.

- In Go, it's possible to include multiple packages in the same repository.  Our
  Go build system does not handle this very well and it's not possible to use
  multiple such packages as dependencies: you need to create a union.  See
  go-golang-org-x-crypto-union.

Let me know if you need more help, I can look into it.

Good luck!

-- 
Pierre Neidhardt
https://ambrevar.xyz/

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]