I would pay attention to
*with exported functions and variables.Fxfunc SomeFunc() {}*
*https://golang.org/ref/spec#Exported_identifiers*
Den onsdag den 30. november 2016 kl. 20.13.10 UTC+1 skrev Craig Peterson:
>
> From the 1.8 plugin docs <https://tip.golang.org/pkg/plugin/>:
>
> A plugin is a Go main package with exported functions and variables
>
>
> This creates a bit of a headache for me. My current setup is that a plugin
> is a simple library package like so:
>
> package someLibrary
>
> import "gihub.com/someapp/pluginRegistry"
>
>
> func init(){
> pluginRegistry.Register(myPlugin)
> }
>
> This works well, but requires being compiled in (usually with an
> import _ "someLibrary"
> in main somewhere)
>
> I would also like to add support for these plugins to be compiled
> independently and loaded at runtime.
>
> In order to do with the plugin package, I need to write a little shim
> package that is literally:
>
> package main
>
>
> import _ "someLibrary"
>
>
> func main(){}
>
> and build that as a plugin.
>
> This feels like unnecessary boilerplate to me. Can anyone explain what are
> the technical reasons for requiring a main package? Could the compiler not
> generate a main package shim like this if you try to build a library
> package with -buildmode=plugin ?
>
--
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 golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
