>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 ''
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
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/