>Once again, I decide to work on modularizing Viking. I did relative >success already: >https://github.com/guyou/viking/tree/feature-plugins
Unfortunately this won't work on Windows (or probably MAC OS) without further edits. Since it uses '<glob.h>' So need to check glob is available for the platform in configure.ac & surround by #ifdefs appropriately. glob() is not available on at least Windows https://stackoverflow.com/questions/15052998/what-to-substitute-for-glob-t-and-glob-on-port-to-windows So some other method for loading plugins from a directory is also needed. Note for: pattern = g_strdup_printf("%s/*.so", dir); In Windows it would be *.dll For the '/' it should be G_PATH_SEPARATOR_S. E.g. see vikdemlayer.c + vikmapslayer.c where G_PATH_SEPARATOR_S is used. Although we don't really support MAC OS, we at least should make some minimal effort to make it likely to work. Here it seems it would be *.dylib files. See: https://docstore.mik.ua/orelly/unix3/mac/ch05_03.htm >In order to go one more step forward, I have to reduce the number of >occurrences of "#ifdef HAVE_XXX". >To do so, I identified two possible solutions. >1) convert Mapnik feature as a MapSource. >This will allow to move this *huge* feature as a dynamic plugin. The vikmapniklayer layer has various options that are specific to Mapnik. Would these need to go into the MapSource ? If so how would you keep keep compatibility from existing .vik files to then convert into the new MapSource type? >2) merge VikLayer and VikLayerInterface. >I think this is something I would made when I refactor part of viking, >years ago. But I was too young or too lazy. :-) >Doing such refactoring will allow to have all VikLayer based class as >dynamic modules. This definitely sounds a good idea. > 3) anything else? Any idea? Overall I'm not entirely sure of who or what having dynamic layer plugins really helps. I don't see the overall size of the program any significant factor, it's not as if Viking is particularly big. I don't see how it would particularly help anyone who actually builds code, since the whole program is open source they could change any of it as they see fit. And/or control it via the build time configuration. I don't see anyone wanting to or going to start distributing binary plugins. And would you trust some-else's generated binary code?? - other than via official distributions] Does this then limit the Viking own internal binary interfaces, as then one can't update things that get used in the check_int, post_init & unload stages - without potentially breaking any previous plugin binaries? Or simply declare no plugin compatibility guarantees between Viking releases. Otherwise need to explicitly work out & document what those interfaces are. -- Be Seeing You - Rob. If at first you don't succeed, then skydiving isn't for you. ________________________________________ From: Guilhem Bonnefille <guilhem.bonnefi...@gmail.com> Sent: 21 August 2018 08:12:18 To: viking devel Subject: [Viking-devel] Modularization(plugin)... again Hi, Once again, I decide to work on modularizing Viking. I did relative success already: https://github.com/guyou/viking/tree/feature-plugins In order to go one more step forward, I have to reduce the number of occurrences of "#ifdef HAVE_XXX". To do so, I identified two possible solutions. 1) convert Mapnik feature as a MapSource. This will allow to move this *huge* feature as a dynamic plugin. 2) merge VikLayer and VikLayerInterface. I think this is something I would made when I refactor part of viking, years ago. But I was too young or too lazy. :-) Doing such refactoring will allow to have all VikLayer based class as dynamic modules. 3) anything else? Any idea? But before doing this, I wish to be sure nobody is working on similar feature or similar significant refactoring. Other though: should we integrate modularization/plugin into 1.7 or 2.0? -- Guilhem BONNEFILLE -=- JID: gu...@im.apinc.org MSN: guilhem_bonnefi...@hotmail.com -=- mailto:guilhem.bonnefi...@gmail.com -=- http://nathguil.free.fr/ ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Viking-devel mailing list Viking-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/viking-devel Viking home page: http://viking.sf.net/ ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Viking-devel mailing list Viking-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/viking-devel Viking home page: http://viking.sf.net/
