[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