Hi Francesco, > same here. The --enable-shared/--disable-shared options are simply > ignored by wxCode component build systems (not only by wxsqlite3).
Interestingly the log messages of the configure tell exactly what the user wants (static build of the wxCode component used with a shared build of wxWidgets), only the generated makefile does not work like expected. It would be better if the configure script would complain about mismatched options instead. > Currently the configuration you give to the configure script (using the > --enable-debug,--enable-unicode,--with-wxshared options) or to the win32 > makefiles (using WX_DEBUG, WX_UNICODE, WX_SHARED) _must_ match the > configuration of a wxWidgets build. > > I hope I cleared the issue :) Well, yes, but I remember there was a discussion quite long ago regarding exactly this issue, that is, building a wxCode component with options not matching the used wxWidgets build options. And I thought the WX_SHARED option was introduced just to solve this issue. But I may be mistaken. > Now there are two solutions to fix this problem: > > 1) remove from the configure.ac of all wxCode components the "wxshared" > option and leave only the "shared" option. Then set in the > WXCODE_OPTIONS macro WX_SHARED=$SHARED (just like it does for > WX_DEBUG=$DEBUG and WX_UNICODE=$UNICODE). > This would mean that you can build your component only with a > combination of debug/unicode/shared settings matching an existing > wxWidgets build. I think this is too restrictive. At least I know there are several users using a shared wxWidgets build but a static wxCode component build. > 2) add to wxCode bakefiles the declaration of an option called "SHARED", > which can be used to build a wxCode component with SHARED!=WX_SHARED. So > that you can build your component in static mode against a shared build > of wxWidgets (the viceversa is not possible for linking reasons). > > Then change in the bakefiles of all components the lines: > > <lib ... cond="WX_SHARED=='0'"> > <dll ... cond="WX_SHARED=='1'"> > > to: > > <lib ... cond="SHARED=='0'"> > <dll ... cond="SHARED=='1'"> > > Last, add the necessary modification to wxCode autoconf macros to handle > the SHARED option as a separed option from WX_SHARED. > > Solution #2 is more difficult but I've already implemented it > successfully for wxLua a while ago, so that I could copy the required > portions of code. > However it requires a change in all wxCode bakefiles and also makes them > somewhat less intuitive. > > The question is: how useful is the ability to do a static build of a > wxCode component against a shared build of wx? > > Under linux it may be useful: so that you can build an ELF > self-contained _except_ for wx DLLs (or better "shared objects) which > are included by deafult in almost all linux distro... > > What's your thoughts? I'm a bit undecided. Up to now I myself have never used different build options for wxCode components and wxWidgets itself, but if there are users demanding this option I guess the wxCode components should offer it if it's not too difficult to implement. If you decide to change the wxCode build system accordingly it should be thoroughly tested before releasing any components using it. At least the current version of the wxCode build system is stable. A third solution would be to change only the behaviour of the configure script, that is, it should reject mismatched shared/static options. A user wishing to make a static build while using a shared wxWidgets build can always add the wxCode component's source files to his own project. Regards, Ulrich ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ wxCode-users mailing list wxCode-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxcode-users
