[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/
signature.asc
Description: PGP signature