Ulrich Telle ha scritto:
> 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.
this should be already done: try to give --enable-shared --without-wxshared.
It doesn't complain on the opposite case since it should be allowed to
give --disable-shared --with-wxshared; it's just that the bakefile part
for the SHARED option is missing.
>> 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.
I think we discussed something similar (i.e. whether we should use as
option names BUILD/SHARED/UNICODE as win32 wx makefiles do or rather
WX_DEBUG/WX_SHARED/WX_UNICODE option names -- we decided for the
latter)... but I don't think they we decided about coexistence of SHARED
and WX_SHARED...
>> 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.
actually I tried to implement it and it results easier than I thought.
> 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.
sure. I have just committed updated version of wxCode bakefiles both to
CVS and SVN.
I tested the changes with 'gnu' and 'autoconf' format for now and they
works well. Before I proceed changing all wxCode bakefiles from
<lib ... cond="WX_SHARED=='0'">
<dll ... cond="WX_SHARED=='1'">
to:
<lib ... cond="SHARED=='0'">
<dll ... cond="SHARED=='1'">
I'd appreciate if other peoples tested the modified build system...
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
