wxlua-users Mailing List for wxLua

Hi,
John Labenski ha scritto:
> On 2/2/06, Francesco Montorsi <f18...@ya...> wrote:
>> Hi,
>> why do we have both:
>> modules/wxbind/src/wxluasetup.h
>> bindings/wxwidgets/wxluasetup.h.in
>>
>> is the last one something old which should be removed ?
> 
> bindings/wxwidgets/wxluasetup.h.in
> 
> is supposed to be a base version of wxluasetup.h that people can start
> from, I guess it can be removed when you move
> 
> modules/wxbind/src/wxluasetup.h
> to
> modules/setup/wxluasetup.h
> 
> I removed the #include "bindings/wxwidgets/wxluasetup.h.in" in
> modules/wxlua/src/internal.cpp. I guess it's not necessary anymore or
> it was just left over from before.
Thanks for the changes.
Currently I implemented what we discussed about the WXLUASETUP_DIR and 
WXLUABINDLIB_DIR options creating a new bakefile in
modules/wxbind/build
so I thought that it was a 'cleaner' idea to put wxluasetup.h in
modules/wxbind/setup
instead of modules/setup. After all, wxluasetup.h is a setup for wxbind, 
right ?
I still need to test the makefiles in modules/wxbind/build; they are 
just a first rough draft. I'll work on them tomorrow.
Francesco

klaas.holwerda ha scritto:
> Hi,
> 
> Using the VC project file, this wxlua_msd_wxbindstc.lib is missed.
> What should i do to get it ? I do not see a target for it.
This should be fixed now.
Francesco

Hi,
Using the VC project file, this wxlua_msd_wxbindstc.lib is missed.
What should i do to get it ? I do not see a target for it.
Thanks,
klaas
 

Just to say i am all fine with what is proposed. It sounds good to me.
Klaas
John Labenski wrote:
>On 2/2/06, Francesco Montorsi <f18...@ya...> wrote:
> 
>
>>>I wonder first why wxluasetup.h is located in a source directory while
>>>it is a header file??
>>> 
>>>

On 2/2/06, Francesco Montorsi <f18...@ya...> wrote:
> Hi,
> why do we have both:
> modules/wxbind/src/wxluasetup.h
> bindings/wxwidgets/wxluasetup.h.in
>
> is the last one something old which should be removed ?
bindings/wxwidgets/wxluasetup.h.in
is supposed to be a base version of wxluasetup.h that people can start
from, I guess it can be removed when you move
modules/wxbind/src/wxluasetup.h
to
modules/setup/wxluasetup.h
I removed the #include "bindings/wxwidgets/wxluasetup.h.in" in
modules/wxlua/src/internal.cpp. I guess it's not necessary anymore or
it was just left over from before.
Regards,
 John Labenski

On 2/2/06, Francesco Montorsi <f18...@ya...> wrote:
> > 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.
That sounds fine, I put wxluasetup.h in the src dir for the reason you stat=
ed.
> > 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 le=
ss.
> >
> > 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 ?
I think it's good. I think it's better to compile your app and link
against a stripped down wxluabinding lib rather than try to remove
stuff at runtime. This way the linker can remove wxWidgets classes
that aren't used as well. If you take wxLua with everything then you
have to drag all of wxWidgets in too since it'll be referenced in the
binding code.
Regards,
 John Labenski

Hi,
 why do we have both:
modules/wxbind/src/wxluasetup.h
bindings/wxwidgets/wxluasetup.h.in
is the last one something old which should be removed ?
Thanks,
Francesco

Hi,
klaas.holwerda ha scritto:
>> Anyway, on Unix, it wouldn't be such difficult to provide to the guest 
>> app X the required info to recompile wxLua's wxbind module.
>> It would probably be somewhat more difficult on win32, but probably 
>> still feasible.
> 
> I think setting the variables inside the App its makefiles should/could 
> do the job.
> Why would it be complicated ? If the variabes are set, you the same as 
> with wxbind, but here with different locations.
it is 'complicated' because the app X needs to compile sources located 
in wxLua.
Let's say (on Unix) that the user compiles and installs wxLua and then 
removes the wxLua directory which he used to compile it.
app X is then unable to compile its custom wxbind module since wxbind 
sources do not exist anymore on that system.
This should not be a problem on win32 since if you want to compile app X 
then you probably won't remove the wxbind's sources of wxLua :)
However, let's say that we install wxbind sources somewhere (maybe 
$(prefix)/share/wxlua/wxbind/src and 
$(prefix)/share/wxlua/wxbind/include). Then, on Unix, the app X would 
need to just add to its makefile a call like:
MAKEFILE=`pkg-config wxlua --variable=wxbindcustom-makefile-location`
make -f $MAKEFILE WXLUASETUP_DIR=/myproject/... 
WXLUABINDLIB_DIR=myproject/... customwxbind
On win32 provided that a WXLUA environment variable exists:
nmake -f %WXLUA%/modules/wxbind/build/msw/makefile.vc 
WXLUASETUP_DIR=/myproject/... WXLUABINDLIB_DIR=myproject/... customwxbind
Ok, after all it's not that difficult :)
Francesco

Francesco Montorsi wrote:
> Hi,
> thinking to implementation of the WXLUASETUP_DIR and 
> WXLUABINDLIB_DIR options, I realized one thing.
>
> I.e. if I want to install app X (from sources) which has its own wxLua 
> extensions, then I cannot just compile&install wxLua with a standard 
> "./configure && make && make install" (on win32 "cd wxLua/build/msw && 
> nmake -fmakefile.vc"): app X requires wxLua's build options to be 
> modified (i.e. adding something like WXLUASETUP_DIR=X/luaext 
> WXLUABINDLIB_DIR=X/lualib).
>
> Ok, this affects only source builds and it won't be the first case 
> that such thing happens. However I think that if that can be avoided, 
> it would be a Good Thing.
Absolutely, wxLua is one fixed thing which can be compiled and installed 
, recompiling whatever bindings in an App, using binding files from 
wxLua is another thing.
>
> One way to avoid that could be providing the app X with a way to 
> recompile the wxLua's wxbind module with its own wxluasetup.h.
Rigth and also the location of the library generated as result.
> This means that the custom wxbind module would not be generated when 
> wxLua is compiled but rather when app X is compiled.
Exactly, the app only uses stuff from there.
>
> I'm not sure if you had this same idea when you wrote that 
> WXLUASETUP_DIR and WXLUABINDLIB_DIR options should not be exposed in 
> the configure script :)
>
At least you got it somehow, but indeed that is what i meant to explain :-)
> Anyway, on Unix, it wouldn't be such difficult to provide to the guest 
> app X the required info to recompile wxLua's wxbind module.
> It would probably be somewhat more difficult on win32, but probably 
> still feasible.
I think setting the variables inside the App its makefiles should/could 
do the job.
Why would it be complicated ? If the variabes are set, you the same as 
with wxbind, but here with different locations.
>
>
> What do you think of this approach ?
I think it right,
Klaas

Hi,
 thinking to implementation of the WXLUASETUP_DIR and 
WXLUABINDLIB_DIR options, I realized one thing.
I.e. if I want to install app X (from sources) which has its own wxLua 
extensions, then I cannot just compile&install wxLua with a standard 
"./configure && make && make install" (on win32 "cd wxLua/build/msw && 
nmake -fmakefile.vc"): app X requires wxLua's build options to be 
modified (i.e. adding something like WXLUASETUP_DIR=X/luaext 
WXLUABINDLIB_DIR=X/lualib).
Ok, this affects only source builds and it won't be the first case that 
such thing happens. However I think that if that can be avoided, it 
would be a Good Thing.
One way to avoid that could be providing the app X with a way to 
recompile the wxLua's wxbind module with its own wxluasetup.h.
This means that the custom wxbind module would not be generated when 
wxLua is compiled but rather when app X is compiled.
I'm not sure if you had this same idea when you wrote that 
WXLUASETUP_DIR and WXLUABINDLIB_DIR options should not be exposed in the 
configure script :)
Anyway, on Unix, it wouldn't be such difficult to provide to the guest 
app X the required info to recompile wxLua's wxbind module.
It would probably be somewhat more difficult on win32, but probably 
still feasible.
What do you think of this approach ?
Francesco

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

On 2/2/06, k. holwerda <kla...@nl...> wrote:
> >> On 2/1/06, Francesco Montorsi <f18...@ya...> wrote:
> >>
> >>>>>>> 1) STC (more generically CONTRIB) problem
> >>>>>>
> >>>> I tried to disconnect wxSTC from the wxWidgets wrappers last night. =
I
> >>>> think it will take some doing however. Since they'll share the same
> >>>> lua namespace, they don't have to, but I would like the generic
> >>>> flexibility of putting multiple wrappers into the same namespace, an=
y
> >>>> additional wrappers overwrite earlier ones. I have to do some readin=
g
> >>>> up on how to add more to lua in C. I hope it won't be too hard.
> >>>
> >>> ok, let me know if I can help in some way...
> >>
> >> I believe I got it to work. It currently generates a library that you
> >> link to in addition to the wxbind library. You can now add any
> >> arbitrary number of libraries to any lua namespace.
> >
> I will test against the sample wxluacan, is something special needed?
> I still have no answer on if i can add it or not? What is the problem?
Yes, please add it. I forgot to respond.
> > there is the possibility that some day wx contrib stuff will be moved
> > in wxCode or somewhere else... so I would use
> > wxLua/bindings/wxstc/stc.i rather than
> > wxLua/bindings/wxwidgets/contrib/stc/stc.i ...
>
> me too.
Ok all done and committed. I haven't updated the bakefiles, but the
Makefiles work in linux.
-John Labenski

Francesco Montorsi wrote:
> Hi,
>
> John Labenski ha scritto:
>
>> On 2/1/06, Francesco Montorsi <f18...@ya...> wrote:
>>
>>>>>>> 1) STC (more generically CONTRIB) problem
>>>>>>
>>>> I tried to disconnect wxSTC from the wxWidgets wrappers last night. I
>>>> think it will take some doing however. Since they'll share the same
>>>> lua namespace, they don't have to, but I would like the generic
>>>> flexibility of putting multiple wrappers into the same namespace, any
>>>> additional wrappers overwrite earlier ones. I have to do some reading
>>>> up on how to add more to lua in C. I hope it won't be too hard.
>>>
>>> ok, let me know if I can help in some way...
>>
>>
>> I believe I got it to work. It currently generates a library that you
>> link to in addition to the wxbind library. You can now add any
>> arbitrary number of libraries to any lua namespace.
>
I will test against the sample wxluacan, is something special needed?
I still have no answer on if i can add it or not? What is the problem?
> there is the possibility that some day wx contrib stuff will be moved 
> in wxCode or somewhere else... so I would use 
> wxLua/bindings/wxstc/stc.i rather than 
> wxLua/bindings/wxwidgets/contrib/stc/stc.i ...
me too.
>
>
>> wxLua/modules/wxbindstc/ - same as wxbind
>> * I think this has to be in it's own dir at the same level as wxbind
>
> ok
Oke.
Klaas
-- 
Unclassified

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

Hi,
John Labenski ha scritto:
> On 2/1/06, Francesco Montorsi <f18...@ya...> wrote:
>>>>>> 1) STC (more generically CONTRIB) problem
>>> I tried to disconnect wxSTC from the wxWidgets wrappers last night. I
>>> think it will take some doing however. Since they'll share the same
>>> lua namespace, they don't have to, but I would like the generic
>>> flexibility of putting multiple wrappers into the same namespace, any
>>> additional wrappers overwrite earlier ones. I have to do some reading
>>> up on how to add more to lua in C. I hope it won't be too hard.
>> ok, let me know if I can help in some way...
> 
> I believe I got it to work. It currently generates a library that you
> link to in addition to the wxbind library. You can now add any
> arbitrary number of libraries to any lua namespace.
very nice !
> So, I guess we need to add some more dirs, let me know what you think
> about these.
> 
> wxLua/bindings/wxstc/stc.i
> or wxLua/bindings/wxwidgets/contrib/stc/stc.i (maybe better)
there is the possibility that some day wx contrib stuff will be moved in 
wxCode or somewhere else... so I would use wxLua/bindings/wxstc/stc.i 
rather than wxLua/bindings/wxwidgets/contrib/stc/stc.i ...
> wxLua/modules/wxbindstc/ - same as wxbind
> * I think this has to be in it's own dir at the same level as wxbind
ok
>>>>>> 2) wxLUA_USE_wxCriticalSectionLocker is not defined - maybe it should
>>>>>> be added to wxluasetup.h
>>>>> looking to wxluasetup.h I've found that there is a heading which says
>>>>> that it's generated by "utils/get_luasetup"; however I couldn't find
>>>>> that util.
>>>>> Is that true or that's an old comment?
>>> That is a simple little utility, basicly just grep wxLUA_USE* for the
>>> .i files. I will try to find it if I can.
>> it would be nice to have it in CVS...
> 
> I found it, it's an awk script that was written before we used the
> wxWidgets %if wxUSE_XXX in the bindings so it's pretty dumb and not
> very useful anymore.
> 
> #=======================
> # read in all the .i files, look for "%if" print them out
> 
> grep "%if" *.i | awk 'BEGIN {print("// Automatically generated by
> utils/get_luasetup edit as necessary."); \
> print(""); \
> print("#ifndef __WXLUA_SETUP__");
> print("#define __WXLUA_SETUP__");
> print("") } \
> { len = length(2ドル); printf("#define %s",2ドル); for
> (i=0;i<40-len;i++) { printf(" ") }; print("1") } \
> END { print(""); print("#endif // __WXLUA_SETUP__") }'
> #=======================
No problem for me if we decide to maintain wxluasetup.h by hand.
In that case I will add wxLUA_USE_wxCriticalSectionLocker to it, ok ?
> 
>>>>> 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 ?
> 
> These are things that you can use with configure?
yes, there will be some options like --enable-custom-bindlib=path and 
--with-custom-wxluasetup=path to enable the build of this additional lib.
> How would you make
> it so that you can build wxbind for the apps/wxlua and a different one
> for external programs. Do you have to run configure between building
> each of them?
No, that's not required. I'll just add another wxLua module which is 
enabled only when WXLUABINDLIB_DIR!='' and which includes the 
WXLUASETUP_DIR instead of the dir which contains the std wxluasetup.h.
Francesco

On 2/1/06, Francesco Montorsi <f18...@ya...> wrote:
> >>>>1) STC (more generically CONTRIB) problem
> >
> > I tried to disconnect wxSTC from the wxWidgets wrappers last night. I
> > think it will take some doing however. Since they'll share the same
> > lua namespace, they don't have to, but I would like the generic
> > flexibility of putting multiple wrappers into the same namespace, any
> > additional wrappers overwrite earlier ones. I have to do some reading
> > up on how to add more to lua in C. I hope it won't be too hard.
> ok, let me know if I can help in some way...
I believe I got it to work. It currently generates a library that you
link to in addition to the wxbind library. You can now add any
arbitrary number of libraries to any lua namespace.
So, I guess we need to add some more dirs, let me know what you think
about these.
wxLua/bindings/wxstc/stc.i
 or wxLua/bindings/wxwidgets/contrib/stc/stc.i (maybe better)
wxLua/modules/wxbindstc/ - same as wxbind
 * I think this has to be in it's own dir at the same level as wxbind
> >>>>2) wxLUA_USE_wxCriticalSectionLocker is not defined - maybe it should
> >>>>be added to wxluasetup.h
> >>>
> >>>looking to wxluasetup.h I've found that there is a heading which says
> >>>that it's generated by "utils/get_luasetup"; however I couldn't find
> >>>that util.
> >>>Is that true or that's an old comment?
> > That is a simple little utility, basicly just grep wxLUA_USE* for the
> > .i files. I will try to find it if I can.
> it would be nice to have it in CVS...
I found it, it's an awk script that was written before we used the
wxWidgets %if wxUSE_XXX in the bindings so it's pretty dumb and not
very useful anymore.
#=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
# read in all the .i files, look for "%if" print them out
grep "%if" *.i | awk 'BEGIN {print("// Automatically generated by
utils/get_luasetup edit as necessary."); \
 print(""); \
 print("#ifndef __WXLUA_SETUP__");
 print("#define __WXLUA_SETUP__");
 print("") } \
 { len =3D length(2ドル); printf("#define %s",2ドル); for
(i=3D0;i<40-len;i++) { printf(" ") }; print("1") } \
 END { print(""); print("#endif // __WXLUA_SETUP__") }'
#=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> >>>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 o=
f
> >>wxbind module, which would be created in the WXLUABINDLIB_DIR folder an=
d
> >>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 ?
These are things that you can use with configure? How would you make
it so that you can build wxbind for the apps/wxlua and a different one
for external programs. Do you have to run configure between building
each of them?
Regards,
 John Labenski