wxlua-users Mailing List for wxLua (Page 8)

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

Hi,
John Labenski ha scritto:
> I did make and then make install, still no luck. I've tried setting
> PYTHONPATH, LD_LIBRARY_PATH, LD_RUN_PATH, copying _bottlenecks.[l]a to
> other directories, same exact error. Grrr... this is why I don't like
> to make installing things too complicated because it's very easy to
> make it impossible to figure out how to "just make it work."
Weird. on my (linux) system it works correctly. Maybe it is something 
cygwin-related ?
Can you please try to install bakefile 0.1.9.1 and then replace the 
$(prefix)/lib/bakefile, $(prefix)/share/bakefile/rules and 
$(prefix)/share/bakefile/output folders with respectively the files 
taken from my frm-bakefile/src, frm-bakefile/rules, frm-bakefile/output ?
That should surely work.
Francesco

Hi,
John Labenski ha scritto:
>>Francesco Montorsi ha scritto:
>>
>>>>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...
>>>>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...
>>>>3) wxLua application needs wxStyledTextCtrl wrapper and an error
>>>>should be given when it's not available instead of just failing it at
>>>>runtime (IMO)
> 
> 
> See above about separating it.
> 
> 
>>>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 ?
Francesco