On Friday, December 20, 2024 at 5:49:04 PM UTC-6 Dan Kortschak wrote:
Almost certainly not. The point of module version specification is to
allow reproducible builds. Leaving this up to things outside the
build's dependencies makes this non-achievable.
Well, we agree then, but is this "tool" entry autogenerated by 'go mod
init' and 'go mod tidy' ?
Or, are we supposed to edit the go.mod file and add these by hand?
Also, even in reproducible builds, it would be helpful to have
tool (
"autogen"
"protoc"
)
I have a command "autogenpb" that generates Marshal() and Sort() functions
that needs 'protoc" and "protoc-gen-go" There are several versions of
protoc-gen-go floating around. I don't yet know which ones work and which
ones don't.
I was trying to work with git2go also, and that is different because it
would be helpful to have
tool (
"libgit2" // this is the C library
)
Is this a "go build" thing or a "go install" thing? As in, do you need
"stringer" for running your app or to build your app? Maybe instead of
"tool" it should be "build" and "install" as those are two separate things.
Many questions I'm afraid. Don't get me wrong by that, I think that this
would be really useful, but I'm afraid that in my cases, I simply can not
know about the versions of build requirements -- especially versions of
autogen related things like protoc. Rather than defining the versions
there, it's a lot better idea to use the ones that are already installed by
the distribution. Embedded linux distributions for sure. Also, lots of the
RiscV boards and whatever is available, it's probably better to use
whatever is there -- especially -- if it exists at all.
jcarr
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/golang-nuts/ec737180-00c2-48cc-885a-b3b8db0d2774n%40googlegroups.com.
