[sending this reply to wxcode-users, too]
Hi Ulrich, and all wxCode devs, Ulrich Telle ha scritto: > Although the option --enable-shared=no (or --disable-shared) is > specified when running ./configure running make does not build wxSQLite3 as a > static library but as a shared library. same here. The --enable-shared/--disable-shared options are simply ignored by wxCode component build systems (not only by wxsqlite3). I'm not sure when this bug was introduced (I tried to search in the CVS/SVN history without success)... but I'm sure it worked originally. > Is there anything wrong with my bakefile? there's nothing wrong with your bakefile... however I've found that the problem is deeper. The fact is that your component (like all other wxCode components! I've checked this!) uses WXCODE_OPTIONS([debug,unicode,shared,toolkit,wxshared,wxversion]) in the configure.ac i.e. specifies not only wxshared but also "shared" option. This is wrong. In fact, there's no SHARED option declared in the wxCode bakefile or in your component's bakefile. wx autoconf macros and wx bakefile presets in fact are affected only by the value of WX_SHARED (the --with-wxshared option in fact works as intended). This is confirmed also by the fact that the components' win32 makefiles do not show any SHARED option. I.e. in the way the wxCode presets are currently written, there's no way (both on Windows and on Unix) to build a static version of a component against a shared build of wxWidgets. 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 :) 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. 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. I'm unsure about the right way to proceed. Solution #1 is the simplest one and it's a "safe" route (very easy to implement). Basically it avoids added complexity to wxCode build system at the cost of excluding the build possibility: wx shared + wxCode comp static. 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? Francesco -- ------------------------------------------------------------------------- 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
