User forums > General (but related to Code::Blocks)

Docking library

<< < (5/8) > >>

mandrav:
SnakeChomp, have you ever tried building wxIFM with a wxWidgets-DLL?

mandrav:

--- Quote from: mandrav on August 27, 2005, 12:45:24 pm ---SnakeChomp, have you ever tried building wxIFM with a wxWidgets-DLL?

--- End quote ---

Like I thought: doesn't work...

Anyway, I 've patched the sources to allow for mixed-environment compilations, i.e.:
wx DLL, IFM static
wx DLL, IFM DLL
should also work with wx static and IFM [DLL|static], but I haven't tested it...

Attached is the patch and C::B workspace for wxIFM (extract in top-level wxIFM folder).

[attachment deleted by admin]

SnakeChomp:
Tortoise SVN doesn't like that patch so its pretty useless to me. And by the way, yes wxIFM does work fine when compiled against a wxWidgets DLL. I just tried it. I did have to remove the one WXDLLEXPORT that I had which was on the wxInterfaceManager class (I just put it there once and never did anything with it) but after that all went well. There were quite a few warnings about to inconsistant dll linkage due to the event macros I used, but it still works. I'd personally rather not support using wxIFM itself as a dll due the highly pointless nature of using any kind of DLL in wxWidgets land. You can't upgrade any wx DLL's without recompiling everything that uses them anyhow so it only opens room for disaster with no benefit if wxIFM was a dll too.

mandrav:

--- Quote from: SnakeChomp on August 27, 2005, 10:17:50 pm ---Tortoise SVN doesn't like that patch so its pretty useless to me. And by the way, yes wxIFM does work fine when compiled against a wxWidgets DLL. I just tried it. I did have to remove the one WXDLLEXPORT that I had which was on the wxInterfaceManager class (I just put it there once and never did anything with it) but after that all went well. There were quite a few warnings about to inconsistant dll linkage due to the event macros I used, but it still works. I'd personally rather not support using wxIFM itself as a dll due the highly pointless nature of using any kind of DLL in wxWidgets land. You can't upgrade any wx DLL's without recompiling everything that uses them anyhow so it only opens room for disaster with no benefit if wxIFM was a dll too.

--- End quote ---

You see, the point is that it works for you, but not for me.
* I 'm talking about gcc compilation
* I don't like any kind of warnings in my code (neither should you).
* "I get a tons of warnings but I don't care as long as it works" is not a good response at all, if you don't mind...

I 'm not talking about wxIFM as a DLL itself. I 'm talking about static wxIFM with wxWidgets DLL. The thing is that WXUSINGDLL must be defined but if you use WXDLLEXPORT in wxIFM, it will wrongly use declspec(dllimport) when building it.
Also, you haven't exported any classes, except for that one using WXDLLEXPORT. Gcc doesn't like it. It builds the library (with many warnings) but chokes when trying to build the demo which uses it...

The patch I sent you, fixes all those issues (check only if the static wx case works).

If the patch doesn't work, you have three options:
a) use a command-line patch utility
b) check why it doesn't work. I can guess: I made this patch *outside* wxIFM dir. This means a simple search for "wxIFM\" and replacing it with "" should make tortoise happy...
c) ask someone to help you

Everything contributed to you, you should learn to accept it happily. Phrases like "Tortoise SVN doesn't like that patch so its pretty useless to me." should really be avoided...

Yiannis.

grv575:
It's a standard patch.
cd wxIFN/
patch -p1 -i ../wxifm.diff

tortoise may have the option to remove prefixes (-p1 removes 1 prefix [directory portion])?
otherwise just do the above in MSYS or cygwin

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version