On 20/08/17 19:21, Michael Stapelberg wrote: >> Gccgo has many quirks. One is that it does not use the vendor directory >> (I need to check if this is true with the latest version), so you might >> need to copy vendor into the builddirectory. > > …hopefully only temporarily, though, right? Ideally, we wouldn’t have > any vendored source in our packages.
Gah! Another thing I forgot to talk about! go packaging is hard.. :) Yes, most of the time I kill all vendoring, but there have been some exceptions: 1) small, useless libraries that I see no point in packaging separately; and 2) self-contained parts of a library, that avoid dragging 100s of dependencies. The latter happened to me recently with prometheus: I had removed the vendoring of the consul API, but when I tried to backport that, I realised I'd need to backport consul, docker, and way too many dependencies. Sadly, even if the client API is in a different package, the source packages have long dependency chains. I am starting to think that for some of these packages, having a separate source package with client APIs would make sense. >> BUILDFLAGS := -ldflags \ >> " -X $(METAPKG)/version.Version=$(VERSION)\ >> -X $(METAPKG)/version.Revision=$(REV)\ >> -X $(METAPKG)/version.Branch=$(BRANCH)\ >> -X $(METAPKG)/version.BuildUser=$(USER)\ >> -X $(METAPKG)/version.BuildDate=$(BUILD_DATE)\ >> -X $(METAPKG)/version.GoVersion=$(GO_VERSION)" > > What does METAPKG resolve to? We should consider centralizing these > definitions somewhere. Ah, this is prometheus-specific. All the meta info is stored in the prometheus/common namespace, so I defined that earlier in the rules file. -- Martín Ferrari (Tincho) _______________________________________________ Pkg-go-maintainers mailing list Pkg-go-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers