cmd/go: does not vendor some directories #59182
Labels
modules
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
WaitingForInfo
Issue is not actionable because of missing required information, which needs to be provided.
Milestone
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes.
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
Attempting to
go mod vendor
the package gitlab.com/gomidi/midi results in a criticalcpp/
cgo directory being deleted in its entirety.What did you expect to see?
Complete vendoring and successful cgo compilation.
What did you see instead?
I tried several recommended tricks to force
go mod vendor
to persist the directory, to no avail. I tried:dummy.go
file to thecpp/
directory (the most commonly recommended tip from the Go community).cpp/*
to a parent directory with existing*.go
files, and updating#include
directives to account for the new locations.#include
directives from*.go
files (another Go community recommended tip).#pragma once
or#ifndef
... directives.The only states I am have been able to achieve are:
go mod vendor
deletes thecpp/
directory entirelygo install ./...
complains of missing C/C++ declarationsgo install ./...
complains of duplicate C/C++ declarationsCan someone please explain what the gomidi/midi author should do to correct their
go mod vendor
integration in their CGO code?As a workaround, I am currently using modvendor, but if at all possible, I would prefer to use only built-in go tools.
https://github.com/goware/modvendor
Frankly, the whole go vendoring system behaves awkwardly with cgo (above), with
go install <dev tools>
(no dev dependency tracking ingo.mod
), and with reflection (e.g. enum comparison). I am at a loss to explain why the different built-in Go components often fail to cooperate with each other.The text was updated successfully, but these errors were encountered: