On 9 November 2015 at 17:24, Dirk Hohndel <[email protected]> wrote: > > On Nov 9, 2015, at 6:25 AM, Tomaz Canabrava <[email protected]> wrote: > >> also, unless i'm mistaken, if a plugin is static linked against the >> same .a modules that the executable is linked (core, profile, >> desktop-widges, etc) aren't we are going to distribute the same code >> twice and the plugin size is going to be quite large? > > > Probably, and maybe this is the reason why it's failing. > Please, continue to compile without facebook integration, I'll try to fix > that here by transforming the subsurface_core and subsurface_interface into > dynamic libraries. > > > I am really really not sure that I want that. >
the "plugin concept" usually implies exposing an API to allow third party developers to contribute a feature without interfering with the main application. said application in some cases can also be closed source. in our case the application is open source, so what we can do is simply define a good interface e.g. (ISocialNetworkIntegration as is) and base all possible social network code on that. then, if a developer comes by and says, "alright, i want to add SocialNetworkX support in Subsurface..", then we can just tell him "use ISocialNetworkIntegration, place all your work in folder X and also take a look at how the Facebook code works". from there it's a question of what is a dynamic library and what is statically linked, but overall everything can still be statically linked in the Subsurface binary. conceptually the source tree will still be separated in modules. but having what is compiled and distributed as modules also has benefits, because using shared libraries *implies* good modular separation. e.g.: subsurface subsurface_core.so subsurface_desktop.so subsurface_socialnetwork_facebook.so subsurface_socialnetwork_x.so ... lubomir -- _______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
