Thread: [wxCode-users] bakefile problems with --enable-shared option

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

[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

-- 