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