wxlua-users — wxLua list for users and developers

Re: [Wxlua-users] lua naming convention change for named enums as class members

[John L. <jla...@gm...>]

On 2/3/06, k. holwerda <kla...@nl...> wrote:
> John Labenski wrote:
>
> >are in wxLua as just "wx.enum1". I propose that it be changed to
> >"wx.MyClass_enum1" where we throw away the enum name, but keep the
> >class name. This way we unclutter the global wx namespace with
> >seemingly arbitrary enum values which should logically tie them more
> >closely to the class that they actually belong to and are used with. I
> >think that to go as far as calling the enums
> >"wx.MyClass_SomeEnumType_enum1" is probably too much and I don't think
> >we'll run into to problems by not bothering to implement that since
> >C/C++ doesn't enforce you to use the enum name anyway.
> >
> >Anyone have any concerns about this change?
> >
> Even in C++ one gets the enum value with
>
> MyClass::enum1
>
> like e.g. :
>
> a2dFill* clone =3D m_fill->TClone( MyClass::enum1 );
>
> That is without the SomeEnumType in it..
> So why not do:
>
> wx.MyClass.enum1
>
> or
>
> wx.MyClass:enum1
>
> I don't understand the _ there. Of is it impossible to do it like that??

Because we'd have to make a table of the enum values for each class
name requiring far more complicated code. I thought that just using an
underscore would be a happy medium.

Regards,
    John Labenski

Re: [Wxlua-users] Re: Why wxluasetup.h.in and wxluasetup.h ?

[k. h. <kla...@nl...>]

But still when wxbindstc also depends on

wxluasetup.h

better use one wxluasetup.h in:

modules/setup

which both bindings modules do use.

This is actually what i saw today in apps.bkl ??

        <!-- always use wxLua's official wxluasetup.h -->
        <include>$(WXLUA_BASEDIR)/modules/setup</include>

Klaas


John Labenski wrote:

>>>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 ?
>>>      
>>>
>>But that is putting it in a module. While there are already two binding
>>modules.
>>I am not sure it they use the same wxluasetup.h, but if yes i would say
>>it has to be in:
>>
>>modules/setup
>>
>>Currently i see a wxluasetup.h in wxbindstc/src  too.
>>
>>or in a new include dir in:
>>
>>modules/bindings/include
>>
>>I can imagine that this file can be used module broad for more then
>>setting bindings on/off.
>>    
>>
>
>That's where it gets a little tricky. The wxSTC binding also depends
>on the wxLUA_USE stuff, for example wxPoint, wxColour, wxWindow, etc,
>but I really don't want to have to go nuts and cross link all the
>dependencies since it'll make things very complicated.
>
>I suppose the best solution is to use the wxSTC bindings without any
>wxluasetup.h file and in a doc file just state the things that have to
>be turned on to make it work. It should be pretty obvious to people
>that if they want a complicated widget like wxSTC they have to bind to
>a large portion of wxWidgets.
>
>
>  
>

-- 
Unclassified

Re: [Wxlua-users] error

[John L. <jla...@gm...>]

On 2/3/06, k. holwerda <kla...@nl...> wrote:
>
> I get this error. I think it is actually a C++ problem, it looks like an
> empty initialization is not allowed.
> Maybe use:
>
> static WXLUAMETHOD builtinList[1];
>
> or some dummy??
>
> c:\data\art2d\wxluacvs\wxLua\modules\wxbindstc\src\wxstc_builtin.cpp(33)
> : error C2059: syntax error : '}'
> c:\data\art2d\wxluacvs\wxLua\modules\wxbindstc\src\wxstc_builtin.cpp(34)
> : error C2501: 'count' : missing storage-class or type specifiers
> c:\data\art2d\wxluacvs\wxLua\modules\wxbindstc\src\wxstc_builtin.cpp(34)
> : error C2065: 'builtinList' : undeclared identifier
>
>
> WXLUAMETHOD* wxLuaGetBuiltinList_wxstc(size_t &count)
> {
>     static WXLUAMETHOD builtinList[] =3D
>     {
>     };
>     count =3D (sizeof(builtinList)/sizeof(builtinList[0]));
>     return builtinList;
> }

Heh, woops, gcc doesn't complain about that, fixed now.

Regards,
    John Labenski

Re: [Wxlua-users] Re: Why wxluasetup.h.in and wxluasetup.h ?

[John L. <jla...@gm...>]

On 2/3/06, Francesco Montorsi <f18...@ya...> wrote:
> Hi,
>
> John Labenski ha scritto:
> >>> 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 ?
> >> But that is putting it in a module. While there are already two bindin=
g
> >> modules.
> >> I am not sure it they use the same wxluasetup.h, but if yes i would sa=
y
> >> it has to be in:
> >>
> >> modules/setup
> >>
> >> Currently i see a wxluasetup.h in wxbindstc/src  too.
> >>
> >> or in a new include dir in:
> >>
> >> modules/bindings/include
> >>
> >> I can imagine that this file can be used module broad for more then
> >> setting bindings on/off.
> >
> > That's where it gets a little tricky. The wxSTC binding also depends
> > on the wxLUA_USE stuff, for example wxPoint, wxColour, wxWindow, etc,
> > but I really don't want to have to go nuts and cross link all the
> > dependencies since it'll make things very complicated.
> >
> > I suppose the best solution is to use the wxSTC bindings without any
> > wxluasetup.h file and in a doc file just state the things that have to
> > be turned on to make it work. It should be pretty obvious to people
> > that if they want a complicated widget like wxSTC they have to bind to
> > a large portion of wxWidgets.
> even better, I think that a set of blocks like:
>
> #if !wxLUA_USE_REQUIREDFEATURE
>         #error Cannot build wxSTC bindings with wxLUA_USE_REQUIREDFEATURE=
 =3D 0 !
> #endif
>
> could be very useful...

Could be a pain in the ass to maintain too. :)  Remember that if you
do this then the wxSTC binding has to find the wxluasetup.h file that
was used for the wxWidgets bindings. I don't think that people will
have a hard time understanding that if they want to use wxSTC they've
got to include the classes it depends on.

> PS: BTW on my local copy I see now two wxluasetup.h; one in
> modules/wxbind/setup and one in modules/wxbindstc/src.
> If I understood correctly, the last one can be removed, right ?

Not yet, the bindings have to be rewritten to not use it.

> What about the first one ? John, do you agree with Klaas that it should
> be moved one level up (in modules/setup) ?

Ehhhh, I think it's not a general wxLua setup file, but rather that
it's just for the wxWidgets bindings. I like your idea of putting it
in wxbind/setup. If there are ever any other bindings, they may have
their own setup files. I'd leave it where it is.

-John

[Wxlua-users] Re: Why wxluasetup.h.in and wxluasetup.h ?

[Francesco M. <f18...@ya...>]

Hi,

John Labenski ha scritto:
>>> 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 ?
>> But that is putting it in a module. While there are already two binding
>> modules.
>> I am not sure it they use the same wxluasetup.h, but if yes i would say
>> it has to be in:
>>
>> modules/setup
>>
>> Currently i see a wxluasetup.h in wxbindstc/src  too.
>>
>> or in a new include dir in:
>>
>> modules/bindings/include
>>
>> I can imagine that this file can be used module broad for more then
>> setting bindings on/off.
> 
> That's where it gets a little tricky. The wxSTC binding also depends
> on the wxLUA_USE stuff, for example wxPoint, wxColour, wxWindow, etc,
> but I really don't want to have to go nuts and cross link all the
> dependencies since it'll make things very complicated.
> 
> I suppose the best solution is to use the wxSTC bindings without any
> wxluasetup.h file and in a doc file just state the things that have to
> be turned on to make it work. It should be pretty obvious to people
> that if they want a complicated widget like wxSTC they have to bind to
> a large portion of wxWidgets.
even better, I think that a set of blocks like:

#if !wxLUA_USE_REQUIREDFEATURE
	#error Cannot build wxSTC bindings with wxLUA_USE_REQUIREDFEATURE = 0 !
#endif

could be very useful...

Francesco


PS: BTW on my local copy I see now two wxluasetup.h; one in 
modules/wxbind/setup and one in modules/wxbindstc/src.
If I understood correctly, the last one can be removed, right ?

What about the first one ? John, do you agree with Klaas that it should 
be moved one level up (in modules/setup) ?

Re: [Wxlua-users] Re: Why wxluasetup.h.in and wxluasetup.h ?

[John L. <jla...@gm...>]

> > 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 ?
>
> But that is putting it in a module. While there are already two binding
> modules.
> I am not sure it they use the same wxluasetup.h, but if yes i would say
> it has to be in:
>
> modules/setup
>
> Currently i see a wxluasetup.h in wxbindstc/src  too.
>
> or in a new include dir in:
>
> modules/bindings/include
>
> I can imagine that this file can be used module broad for more then
> setting bindings on/off.

That's where it gets a little tricky. The wxSTC binding also depends
on the wxLUA_USE stuff, for example wxPoint, wxColour, wxWindow, etc,
but I really don't want to have to go nuts and cross link all the
dependencies since it'll make things very complicated.

I suppose the best solution is to use the wxSTC bindings without any
wxluasetup.h file and in a doc file just state the things that have to
be turned on to make it work. It should be pretty obvious to people
that if they want a complicated widget like wxSTC they have to bind to
a large portion of wxWidgets.

Regards,
    John Labenski

[Wxlua-users] Re: bakefile generation

[Francesco M. <f18...@ya...>]

k. holwerda ha scritto:
> Hi Francesco,
> 
> How do i generate using nakefile.
> 
> I did get the latest bakefile version, and yours, copied what i thought 
> would be needed into the othere.
> Bad luck, i get errors hen calling bakefile_gen.
> 
> That is windows.
which error did you get ?

Francesco


PS: I know that using my patched version can be a trouble since it has 
no win32 installer; so I try to keep wxLua makefiles always updated so 
that you don't have to regen them...

[Wxlua-users] bakefile generation

[k. h. <kla...@nl...>]

Hi Francesco,

How do i generate using nakefile.

I did get the latest bakefile version, and yours, copied what i thought 
would be needed into the othere.
Bad luck, i get errors hen calling bakefile_gen.

That is windows.

How can i organize a proper bakefile generator?

Klaas

-- 
Unclassified

[Wxlua-users] error

[k. h. <kla...@nl...>]

Hi

I get this error. I think it is actually a C++ problem, it looks like an 
empty initialization is not allowed.
Maybe use:

static WXLUAMETHOD builtinList[1];

or some dummy??

c:\data\art2d\wxluacvs\wxLua\modules\wxbindstc\src\wxstc_builtin.cpp(33) 
: error C2059: syntax error : '}'
c:\data\art2d\wxluacvs\wxLua\modules\wxbindstc\src\wxstc_builtin.cpp(34) 
: error C2501: 'count' : missing storage-class or type specifiers
c:\data\art2d\wxluacvs\wxLua\modules\wxbindstc\src\wxstc_builtin.cpp(34) 
: error C2065: 'builtinList' : undeclared identifier


WXLUAMETHOD* wxLuaGetBuiltinList_wxstc(size_t &count)
{
    static WXLUAMETHOD builtinList[] =
    {
    };
    count = (sizeof(builtinList)/sizeof(builtinList[0]));
    return builtinList;
}

Klaas


-- 
Unclassified

Re: [Wxlua-users] lua naming convention change for named enums as class members

[k. h. <kla...@nl...>]

John Labenski wrote:

>are in wxLua as just "wx.enum1". I propose that it be changed to
>"wx.MyClass_enum1" where we throw away the enum name, but keep the
>class name. This way we unclutter the global wx namespace with
>seemingly arbitrary enum values which should logically tie them more
>closely to the class that they actually belong to and are used with. I
>think that to go as far as calling the enums
>"wx.MyClass_SomeEnumType_enum1" is probably too much and I don't think
>we'll run into to problems by not bothering to implement that since
>C/C++ doesn't enforce you to use the enum name anyway.
>
>Anyone have any concerns about this change?
>  
>
Even in C++ one gets the enum value with

MyClass::enum1

like e.g. :

a2dFill* clone = m_fill->TClone( MyClass::enum1 );

That is without the SomeEnumType in it..
So why not do:

wx.MyClass.enum1

or

wx.MyClass:enum1

I don't understand the _ there. Of is it impossible to do it like that??


Klaas


-- 
Unclassified

Re: [Wxlua-users] Re: Why wxluasetup.h.in and wxluasetup.h ?

[k. h. <kla...@nl...>]

Hi,

Francesco Montorsi wrote:

>>
>> 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.
>
>
>
> 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 ?

But that is putting it in a module. While there are already two binding 
modules.
I am not sure it they use the same wxluasetup.h, but if yes i would say 
it has to be in:

modules/setup

Currently i see a wxluasetup.h in wxbindstc/src  too.

or in a new include dir in:

modules/bindings/include

I can imagine that this file can be used module broad for more then 
setting bindings on/off.

Klaas

-- 
Unclassified

[Wxlua-users] lua naming convention change for named enums as class members

[John L. <jla...@gm...>]

Currently enums that are part of classes, such as

class MyClass
{
    enum SomeEnumType
    {
        enum1,
        enum2
    };
    ...
};

are in wxLua as just "wx.enum1". I propose that it be changed to
"wx.MyClass_enum1" where we throw away the enum name, but keep the
class name. This way we unclutter the global wx namespace with
seemingly arbitrary enum values which should logically tie them more
closely to the class that they actually belong to and are used with. I
think that to go as far as calling the enums
"wx.MyClass_SomeEnumType_enum1" is probably too much and I don't think
we'll run into to problems by not bothering to implement that since
C/C++ doesn't enforce you to use the enum name anyway.

Anyone have any concerns about this change?

Regards,
    John Labenski

[Wxlua-users] Re: Why wxluasetup.h.in and wxluasetup.h ?

[Francesco M. <f18...@ya...>]

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

[Wxlua-users] Re: wxbindstc??

[Francesco M. <f18...@ya...>]

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

[Wxlua-users] wxbindstc??

[klaas.holwerda <kho...@xs...>]

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
 

Re: [Wxlua-users] Re: Remaining problems on Linux (Re: wxLua on Linux)

[klaas.holwerda <kho...@xs...>]

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??
>>>      
>>>

Re: [Wxlua-users] Why wxluasetup.h.in and wxluasetup.h ?

[John L. <jla...@gm...>]

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

Re: [Wxlua-users] Re: Remaining problems on Linux (Re: wxLua on Linux)

[John L. <jla...@gm...>]

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

[Wxlua-users] Why wxluasetup.h.in and wxluasetup.h ?

[Francesco M. <f18...@ya...>]

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

[Wxlua-users] Re: Custom wxBind library and wxLua

[Francesco M. <f18...@ya...>]

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

Re: [Wxlua-users] Custom wxBind library and wxLua

[klaas.holwerda <kho...@xs...>]

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

[Wxlua-users] Custom wxBind library and wxLua

[Francesco M. <f18...@ya...>]

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

[Wxlua-users] Re: Remaining problems on Linux (Re: wxLua on Linux)

[Francesco M. <f18...@ya...>]

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

Re: [Wxlua-users] Re: Remaining problems on Linux (Re: wxLua on Linux)

[John L. <jla...@gm...>]

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

Re: [Wxlua-users] Re: Remaining problems on Linux (Re: wxLua on Linux)

[k. h. <kla...@nl...>]

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