Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development

[wxSmith] wxSmithContribItems not loaded on Mac OS X

<< < (2/4) > >>

afb:
Without -module / as a dylib, the plugin cannot be loaded by Code::Blocks...

Would it be possible to split wxSmith into one library and one plugin, and then have both plugins (libwxsmith.so and libwxsmithcontribitems.so) link with this library (libwxsmith.dylib) - kinda like how the other plugins do with libcodeblocks.dylib ?

Because if wxSmith is built without -module, it can't be loaded as a plugin (by the dynamic linker). And if it is built with -module, it can't be linked as a library (by the static linker) in the Makefile by for instance by wxSmithContribItems.

afb:
Splitting the module works OK, I called the library "wxsmithlib":
http://www.algonet.se/~afb/wx/codeblocks-wxsmithlib.patch

The Makefile isn't perfect, seems like you can only have one
"libdir" so it installed libwxsmith.so into lib instead of plugins...
You might want to do a different split, I just extracted as little
code as possible out from wxsmith.cpp and wxsmithmime.cpp.

But doing it this way makes wxSmith load again on Mac OS X.
(including the wxSmithMime and wxSmithContribItems plugins)


--- Code: (File sizes) ---4.0K    /usr/local/lib/libwxsmithlib.0.0.1.dylib -> libwxsmithlib.0.dylib
119M    /usr/local/lib/libwxsmithlib.0.dylib
4.0K    /usr/local/lib/libwxsmithlib.dylib -> libwxsmithlib.0.dylib
4.0K    /usr/local/lib/libwxsmithlib.la
4.0K    /usr/local/share/codeblocks/plugins/libwxsmith.la
728K    /usr/local/share/codeblocks/plugins/libwxsmith.so
4.0K    /usr/local/share/codeblocks/plugins/libwxsmithcontribitems.la
7.4M    /usr/local/share/codeblocks/plugins/libwxsmithcontribitems.so

--- End code ---

byo:
Hmm, patch looks fine, simillar to my idea:



+-- wxSmith base -------------------------------------------------+
|                                                                 |
|    +------------------------+        +-----------------------+  |
|    |     Plugin classes     |        |    wxSmith engine     |  |
|    |  * wxSmith             | =====> |  (all other wxSmith's |  |
|    |  * wxSmithMime         |        |   classes)            |  |
|    +------------------------+        +-----------------------+  |
|                                          /\      /\             |
|                                          ||      ||             |
+------------------------------------------||------||-------------+
                                           ||      ||
          ===================================      ||
          ||                                       ||
+-- Contrib items 1 ----+              +-- Contrib items 2 ----+   
|                       |              |                       |   
|                       |              |                       |   
+-----------------------+              +-----------------------+   



So plugin classes are put into .so, they would only forward calls from Code::Blocks into wxSmith engine. The Engine itself would be .dylib object (just like wxsmithlib in your patch) and contrib item classes would connect through engine.

That may have few drawbacks (it won't be able to create .cbplugin for wxSmith), but currently they wont cause any problems.

I'll try to implement this by using your patch (I'm not familliar enough with Makfiles to rely on my own knowledge ;) ) and hope that this will work. And I'll leave one dll in windows since it works fine.

Regards
  BYO

EDIT: I just forgot to mention that current content of wxSmith class will be put into wxSmithEngine because some components my use it's functionality. Old wxSmith class will be only a wrapper for wxSmithEngine - that's the main difference between my solution and yours ;)

byo:
Ok, I studied your patch a little bit better and it looks like I misunderstood few things  :oops:. Looks like everything is right there :) Maybe those two plugin registrands could be put intside one file.

BYO

afb:

--- Quote from: byo on April 24, 2007, 10:18:09 pm ---Maybe those two plugin registrands could be put intside one file.
--- End quote ---

Tried that, but then C++ barfed on two nameless namespaces in one file.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version