|
|
Home » Developing U++ » U++ Developers corner » Support for plug-in architecture
Support for plug-in architecture [message #53211] |
Sat, 21 March 2020 03:21 |
slashupp
Messages: 231 Registered: July 2009
|
Experienced Member |
|
|
(linux)
I have an app that will work well with plug-ins, i.e. using custom-controls that are compiled
into dynamic shared libs that can be loaded by the executable without needing to recompile the
app itself.
My current design generates all as one big blob-executable and needs to be re-build for each small
change or addition of a custom-control, but would be much better using plug-ins.
Since Windows DLL's can be created, why can the linux-equivalent of dynamic shared object (.so) not
be created? It looks like a simple change to compiler and linker flags that will enable this?
I've hacked the [Setup/Build methods] flags to produce a .so lib, which works with well with
'extern "C"'-functions, but fails to pass an accessable custom-control (which is mangled C++) back.
Barring out-of-the-box support for plug-in/.so development, is there any other way to implement a
plug-in design using Upp?
|
|
|
Re: Support for plug-in architecture [message #53212 is a reply to message #53211] |
Sat, 21 March 2020 09:54 |
|
mirek
Messages: 14038 Registered: November 2005
|
Ultimate Member |
|
|
slashupp wrote on Sat, 21 March 2020 03:21(linux)
I have an app that will work well with plug-ins, i.e. using custom-controls that are compiled
into dynamic shared libs that can be loaded by the executable without needing to recompile the
app itself.
My current design generates all as one big blob-executable and needs to be re-build for each small
change or addition of a custom-control, but would be much better using plug-ins.
Since Windows DLL's can be created, why can the linux-equivalent of dynamic shared object (.so) not
be created? It looks like a simple change to compiler and linker flags that will enable this?
I've hacked the [Setup/Build methods] flags to produce a .so lib, which works with well with
'extern "C"'-functions, but fails to pass an accessable custom-control (which is mangled C++) back.
Barring out-of-the-box support for plug-in/.so development, is there any other way to implement a
plug-in design using Upp?
Not at the moment. Somehow this is not much required by typical U++ apps - which quite often are niche engineering applications or custom bussines solutions with tens to hunderds users. Not much need for plugins there.
That said, I am really not sure what is wrong with .so, IMO it should work for mangled C++ names as well.
Anyway, the trouble with .so and C++ is usually the problem that it is very fragile. Swap two virtual methods, add single member variable and the whole thing just explodes... When I was thinking about the best approach, I have tended to think about separate processes and RPC communication.
|
|
|
Re: Support for plug-in architecture [message #53214 is a reply to message #53212] |
Sat, 21 March 2020 13:15 |
slashupp
Messages: 231 Registered: July 2009
|
Experienced Member |
|
|
Hi mirek
I attach my attempt at creating .so for plug-ins.
There are two: plug_one that uses 'standard' c++ class, and the second tries to create a Upp-ctrl as plug-in.
The first works fine after a bit of a fiddle, but the second gives invalid access/segfault for reasons I am yet
to find.
I will appreciate if you or anybody checks over my code and hopefully spot the error.
To create the three packages I used two package dirs: 'temp' to hold the test-app and 'libs' to hold the plug-ins.
I then changed for the plugins the following:
In [Build/Output mode..] I set the 'Target file override' to "~/plug_in_libs/libplug_one.so" and "~/plug_in_libs/libmyctrl.so" after checking 'Release' for each plug-in.
The plugins must be compiled in Release mode.
Also for the plugins I changed each separately in [Setup/Build methods..] the 'Release options' by pre-pending -fPIC to it's content (-fPIC -O3 -ffunction-sections -fdata-sections),
and 'Release link options' to (-shared -Wl,--gc-sections,-soname,libmyctrl.so) and (-shared -Wl,--gc-sections,-soname,libplug_one.so)
for the two plug-ins
((POSSIBLE BUG: the [Setup/Build methods..] are not unique per open theide, a change in one gets reflected in others))
Compile the three packages now as you would do normally and the two .so's will be created in the ~/plug_in_libs directory.
Change the constants in 'plug_one.cpp' to reflect your path to the .so's.
|
|
|
|
|
|
|
|
|
|
|
Goto Forum:
Current Time: Fri Sep 20 06:55:23 CEST 2024
Total time taken to generate the page: 0.04345 seconds
|
|
|