New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cmd/go: Allow building non-main package with -buildmode=plugin #18124
Comments
Turns out this is not so easy. This solution would solve my immediate use case, but only because my plugins do not need to export anything. The generated main package hides the exports from the actual package you want to build, and the host app won't be able to find them with The only solution I can think of is essentially rewriting all go files in the package to a tmp directory and rewriting the import to main. Probably out of scope of what you would be willing to accept for this. Any other ideas? |
I see, you're right, I was thinking more of c-shared and c-archive, where any package can export a symbol (by using a magic cgo |
Does it not seem a bit silly needing to write a main function that never gets executed though? |
I also just hit this issue, as we want to support either dynamic loading of plugins or preloading them during build of the program, I will be generating This will only work for us as we use single variable export as entry point of plugins. |
Is it not possible to treat the package as if it were the main package? It is already possible to build a plugin from a package without a |
go.work in particular is problematic - if you share /a and /b in a workspace, the plugin under /b will error out with |
@titpetric Any updates? I am in a similar situation with go workspaces and I am getting the same error. Thanks. |
I'd suggest reading the plugin godoc, and avoid 'plugin' as the name for the plugin. Plugins do compile in a workspace. |
The plugin package currently requires a
main
package as an entry point to use-buildmode=plugin
. I would like to use the plugin package to load library packages at runtime, which are only used for their initializers. Plugins usually look like:The current methodology is that these are compiled into the host with
import _ "myPlugin"
In order to support loading at runtime as well, each plugin needs a second main package that is literally:This feels like unnecessary boilerplate. At Ian's suggestion I propose modifying the go tool to generate such a main package when using
-buildmode=plugin
and a single non-main package is built.I plan on working on this feature.
The text was updated successfully, but these errors were encountered: