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??
Why not place it in wbind/include?
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.
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.
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.
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.
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.
regards,
Klaas
--
Unclassified
-------------------------------------------------------
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
