Hi,
k. holwerda ha scritto:
Francesco Montorsi wrote:
7) can I start to connect the options WXLUASETUP_DIR and
WXLUABINDLIB_DIR to the build system ?
Before starting this work, I need to know exactly how they must work ;)
If I'm right, they should be used not to *modify* the build of the
wxbind module of wxLua (which should always use the
modules/wxbind/src/wxluasetup.h header and should always go in the lib/
folder) but rather to *create* a new library, built from same
sources of
wxbind module, which would be created in the WXLUABINDLIB_DIR folder
and
which would use the wxluasetup.h found in the WXLUASETUP_DIR path.
Is it right ?
I would be nice to be able to build the wxbind lib for different
wxluasetup.h files, one lib for the wxLua app and others for your
programs that use wxLua as a library. Sorry, I didn't follow this too
closely.
Klaas, IIRC you would use these options... my description above
describe the wanted behaviour correctly, or there is something else
which needs to be done ?
I wonder first why wxluasetup.h is located in a source directory while
it is a header file??
Probably it was put in src/ thinking to the fact that it should be
'overrideable' by an option like WXLUASETUP_DIR.
However I suggest to move wxluasetup.h in a directory ad-hoc like
"wxLua/modules/setup" so that it would still be possible to include it
using lines like:
#include "wxluasetup.h"
(since the wxLua/modules path is automatically added to include search
paths).
I'm proposing this because AFAIK every compiler is free to decide its
own rules about include directories priority. That is, if we keep
'wxluasetup.h' in modules/wxbind/src, even if we give to the compiler
the -I/userpath/to/custom/wxluasetup switch, we cannot be 100% sure that
the compiler will use the /userpath/to/custom/wxluasetup/wxluasetup.h
file instead of the modules/wxbind/src/wxluasetup.h....
If you agree, I'll move wxluasetup.h in wxLua/modules/setup and commit
bakefile changes required to get this option to work.
Why not place it in wbind/include?
because it would always be found by the compiler since the
wxbind/include directory needs to be searched for headers in any case.
This would give no problems when building the wxLua's wxbind lib but it
could give problems when building user's wxbind lib since we need to be
sure to be using the user's custom wxluasetup.h for that.
For application/libraries which want to extend/subset the wxLua bindings
( e.g. have one extra myextra.i file or disable some classes), one needs
to have a wxluasetup.h of his own. So in such a case there must be two
wxluasetup.h files in different locations.
sure
Same for the path where the library will be created.
To extend wxLua in the same lua namespace, the new wxBindings modules
could handle that once they work correctly.
But that would always lead to an extra library in the end. For creating
a subset of the wxLua bindings one will always need a second
wxluasetup.h file.
sure
I think this should not be part of configure.
It is a feature to be able to use the *.i files from wxLua and a
different external wxluasetup.h file, to create an extra bindinglib
which only is oke for the application who needs that. Maybe there or two
application like that and one wants extend/subset X and the other Y.
Also Installation of wxLua on Unix systems should not influence this
mechanism.
I'm not sure to understand what you mean.
Users who do not need to extend wxLua with new bindings would just not
use the -enable-custom-bindlib=path and --with-custom-wxluasetup=path
options.
Developers who need to build wxLua extensions would have to use them
instead.
This leads to another problem I'm going to describe later in another mail...
Although i did not ask for this feature ( John wanted this i think ), i
would be glad with it now, since that would make it possible to use
wxLua as is currently. I would just extend the base binding, and forget
of creating extra bindings using the new mechanism.
Without this feature, that is impossible, i would need to ask users
to modify wxLua internal first. That would be bad.
that would be very bad, indeed.
If all the new moduler binding features would work correctly, there is
still a need for the above. It would be to create a subset of wxLua
bindings to make the base binding library smaller for a specific
application. If one can Unregister things runtime, the need would be less.
All in all i think those variables would be good to have.
Ok, so, in conclusion, my description of the wanted behaviour for those
options is right, isn't it ?
Francesco
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Wxlua-users mailing list
Wxlua-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxlua-users
