It appears this is not a hard requirement. In my tests I can successfully
load a compiled plugin with no exported functions or variables.
On Wednesday, November 30, 2016 at 12:37:23 PM UTC-7, Lars Tørnes Hansen
wrote:
>
> I would pay attention to
>
>
>
>
>
>
> *with exported functions and variables.Fxfunc SomeFunc() {}*
> *https://golang.org/ref/spec#Exported_identifiers
> <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.
