Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » Developing U++ » U++ Developers corner » Support for plug-in architecture
Support for plug-in architecture [message #53211] Sat, 21 March 2020 03:21 Go to next message
slashupp is currently offline  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 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
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... Smile 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 Go to previous messageGo to next message
slashupp is currently offline  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.


Re: Support for plug-in architecture [message #53215 is a reply to message #53214] Sat, 21 March 2020 13:27 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Try USEMALLOC.
Re: Support for plug-in architecture [message #53242 is a reply to message #53215] Tue, 24 March 2020 18:20 Go to previous messageGo to next message
slashupp is currently offline  slashupp
Messages: 231
Registered: July 2009
Experienced Member
Tried USEMALLOC and all permutations of the flags and the best
I could find was GUI MT, but with all that, still no-go.

Strange thing is that the plug-in ctrl is correctly painted when I draw
lines around it's position in the parent window ... don't know why

I attach my current attempt, any help to get this working would be
greatly appreciated (I mean the alternative is Qt deargodno!)

Please help me to get this working in Upp.

thx
Re: Support for plug-in architecture [message #53251 is a reply to message #53242] Wed, 25 March 2020 12:46 Go to previous messageGo to next message
slashupp is currently offline  slashupp
Messages: 231
Registered: July 2009
Experienced Member
Also found that if I call Show() on the plug-in right after AddChild() it shows-up correctly.

I made the plug-in ctrl copy-constructable and some of the custom functions is working now while
others still crash.

Re: Support for plug-in architecture [message #53254 is a reply to message #53251] Wed, 25 March 2020 12:55 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
IF ctrlplug is the plugin, then the obvious problem is that you are linking it second set of U++ libraries. With all inlines we have, it is no wonder it crashes.

Try removing all "used" packages (obviously keep includes). I think the plugin should be just single package.

Mirek
Re: Support for plug-in architecture [message #53266 is a reply to message #53254] Wed, 25 March 2020 14:53 Go to previous messageGo to next message
slashupp is currently offline  slashupp
Messages: 231
Registered: July 2009
Experienced Member
Quote:
Try removing all "used" packages (obviously keep includes). I think the plugin should be just single package.


I don't understand what you mean or how to do that.

Doesn't compile if I remove the "uses" clause from the .upp-file

Re: Support for plug-in architecture [message #53267 is a reply to message #53266] Wed, 25 March 2020 15:35 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
slashupp wrote on Wed, 25 March 2020 14:53
Quote:
Try removing all "used" packages (obviously keep includes). I think the plugin should be just single package.


I don't understand what you mean or how to do that.

Doesn't compile if I remove the "uses" clause from the .upp-file



I see Sad Well, obviously, current build process might not be quite ready for what you need...

You could try, "all shared" option in build setup, but then you will need fake main package. "all shared" should create all packages as .so (except main) and then you should be able to use the single .so as the plugin.

All that said, I am pretty sure this all leads to nothing. What is the purpose to having this plugin architecture?

Mirek
Re: Support for plug-in architecture [message #53270 is a reply to message #53267] Wed, 25 March 2020 16:52 Go to previous messageGo to next message
slashupp is currently offline  slashupp
Messages: 231
Registered: July 2009
Experienced Member
Quote:
You could try, "all shared" option in build setup, but then you will need fake main package. "all shared" should create all packages as .so (except main) and then you should be able to use the single .so as the plugin.


I'll try that, see how far I get.

Quote:
What is the purpose to having this plugin architecture?


I'm writing an app to provide many services extending a {base/'kernel'} set of data & functions, with some of these
services mutually exclusive with respect to each other, and also allowing/enabling different other services. To
provide the services as plug-in's rather than a all-in-one-big-blob-app makes more sense and easier to develop
and maintain.
Re: Support for plug-in architecture [message #53272 is a reply to message #53270] Wed, 25 March 2020 17:51 Go to previous message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
slashupp wrote on Wed, 25 March 2020 16:52
Quote:
You could try, "all shared" option in build setup, but then you will need fake main package. "all shared" should create all packages as .so (except main) and then you should be able to use the single .so as the plugin.


I'll try that, see how far I get.

Quote:
What is the purpose to having this plugin architecture?


I'm writing an app to provide many services extending a {base/'kernel'} set of data & functions, with some of these
services mutually exclusive with respect to each other, and also allowing/enabling different other services. To
provide the services as plug-in's rather than a all-in-one-big-blob-app makes more sense and easier to develop
and maintain.


Why do you think it will be easier to develop and maintain? It will be hell even if you will be able to make it work....
Previous Topic: Proposal: Transition from SVN to GIT within 2020.1 release cycle
Next Topic: umk static version
Goto Forum:
  


Current Time: Thu Mar 28 18:59:56 CET 2024

Total time taken to generate the page: 0.01584 seconds