wxlua-users Mailing List for wxLua

Hi,
    just committed the following build fixes:
-> wx default version is now 2.6
-> DSW/DSP files use CRLF EOL
-> wxLua's configure can be called from any directory
    (running wxLua/mybuild/../configure && make && make install now works)
-> fixed wxLua.dsw

Francesco


Francesco Montorsi ha scritto:
> Hi,
> 
> k. holwerda ha scritto:
> 
>> Hi,
>>
>> John Labenski wrote:
>>
>>>> So leafs the not found target.
>>>>
>>>> I see in the modules a split in sourse and headers, nice!
>>>> Can it be made non capital in all cases?
>>>>
>>>> In apps.dsw, i get can not open wxmsw27d_xrc.lib, indeed that i don't
>>>> have ;-)
>>>> I have wxmsw26d_xrc.lib, how come?
>>>>   
>>>
>>>
>>>
>>> The last update using bakefile has changed from 26 to 27. I use
>>> wxWidgets CVS head so this is not a problem, but we should revert to
>>> 26 since that is the stable brach of wxWidgets.
> 
> sure; that's my fault.
> I'm going to set it in wxLua bakefiles so that won't be a problem anymore.
> 
> 
>>>  
>>>
>> I am suprized why it  is not recognized automatically using WXWIN?
> 
> WXWIN only gives info about location of wxWidgets, not its version.
> 
> 
>>>> How does one deal with stedit in the second target? Maybe that 
>>>> should go
>>>> into install.html too.
>>>>   
>>>
>>>
>>>
>>> What second target?
>>>  
>>>
>> wxluaedit uses stedit, so the second target in that apps.dsw
> 
> if I understand it correctly (please remember that it's quite a bit of 
> time I'm not using MSVC anymore and I don't have a fresh idea of how 
> wxLua project files look and how many are the targets and how they are 
> exactly named :)), this is the same problem I have on linux :)
> 
> See problem #1 in my "Remaining problems" mails
> 
> 
>>>>> Trying to test it.
>>>>>
>>>>> In the project file wxLua.dsw, VC6 could not find target app_wxLua, it
>>>>> seems to search for
>>>>> wxLua/apps/build/msw/apps.dsp.
>>>>> And indeed i could not find it, although there is apps.dsw.
>>>>>
>>>>> Can you fix that?
>>>>>     
>>>
>>>
>>>
>>> apps.dsp has been removed, do another checkout.
> 
> anyway I updated apps.dsw to match the new DSP names
> 
> 
>> And it is all LF again, so no project file works anymore.
> 
> if you are checking out from a win32 box and DSP files were added to CVS 
> repository as text files, this should never happen (CVS should check 
> them out using CRLF). Maybe they were added as binary.
> In frm-bakefile 0.2.0 I have added a --crlf=(native|dos|mac|unix) option 
> which I could use to tell bakefile_gen to generate DSW/DSP files always 
> with dos EOL...
> 
> I'm going to do that ASAP.
> 
> 
>>>>> Is there already a cleanall /deep ?  I see that things get mixed up in
>>>>> project files, so a real good/all clean like in wxArt2D  is needed i
>>>>> think.
> 
> I'll test wxLua project files as soon as linux problems are solved...
> 
> Francesco
> 
> 
> 
> -------------------------------------------------------
> 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

Hi,

k. holwerda ha scritto:
> Hi,
> 
> John Labenski wrote:
> 
>>> So leafs the not found target.
>>>
>>> I see in the modules a split in sourse and headers, nice!
>>> Can it be made non capital in all cases?
>>>
>>> In apps.dsw, i get can not open wxmsw27d_xrc.lib, indeed that i don't
>>> have ;-)
>>> I have wxmsw26d_xrc.lib, how come?
>>>   
>>
>>
>> The last update using bakefile has changed from 26 to 27. I use
>> wxWidgets CVS head so this is not a problem, but we should revert to
>> 26 since that is the stable brach of wxWidgets.
sure; that's my fault.
I'm going to set it in wxLua bakefiles so that won't be a problem anymore.


>>  
>>
> I am suprized why it  is not recognized automatically using WXWIN?
WXWIN only gives info about location of wxWidgets, not its version.


>>> How does one deal with stedit in the second target? Maybe that should go
>>> into install.html too.
>>>   
>>
>>
>> What second target?
>>  
>>
> wxluaedit uses stedit, so the second target in that apps.dsw
if I understand it correctly (please remember that it's quite a bit of 
time I'm not using MSVC anymore and I don't have a fresh idea of how 
wxLua project files look and how many are the targets and how they are 
exactly named :)), this is the same problem I have on linux :)

See problem #1 in my "Remaining problems" mails


>>>> Trying to test it.
>>>>
>>>> In the project file wxLua.dsw, VC6 could not find target app_wxLua, it
>>>> seems to search for
>>>> wxLua/apps/build/msw/apps.dsp.
>>>> And indeed i could not find it, although there is apps.dsw.
>>>>
>>>> Can you fix that?
>>>>     
>>
>>
>> apps.dsp has been removed, do another checkout.
anyway I updated apps.dsw to match the new DSP names


> And it is all LF again, so no project file works anymore.
if you are checking out from a win32 box and DSP files were added to CVS 
repository as text files, this should never happen (CVS should check 
them out using CRLF). Maybe they were added as binary.
In frm-bakefile 0.2.0 I have added a --crlf=(native|dos|mac|unix) option 
which I could use to tell bakefile_gen to generate DSW/DSP files always 
with dos EOL...

I'm going to do that ASAP.


>>>> Is there already a cleanall /deep ?  I see that things get mixed up in
>>>> project files, so a real good/all clean like in wxArt2D  is needed i
>>>> think.
I'll test wxLua project files as soon as linux problems are solved...

Francesco

Hi,

John Labenski ha scritto:
> On 1/23/06, Francesco Montorsi <f18...@ya...> wrote:
> 
>>>>>./../modules/wxbind/include/wxbind.h:127:6: warning: "wxUSE_WAVE" is
>>>>>not defined
> Ok, I've added a new setting in wx.rules where you can add any
> additional code for the binding header. There is where I've placed
> 
> #ifndef wxUSE_WAVE
> #define wxUSE_WAVE 0
> #endif
> 
> so that ti should work anywhere. It's a little bit of a hack, but I
> think this is all we can do to maintain backwards compatibility.
I confirm that wxUSE_WAVE warning is disappeared.

Still we have at least the following problems:

1) STC (more generically CONTRIB) problem

2) wxLUA_USE_wxCriticalSectionLocker is not defined - maybe it should be 
added to wxluasetup.h

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)

4) currently doing a thing like:
      mkdir mybuild && cd mybuild && ../configure && make
    doesn't work. I'm going to fix this tomorrow.

5) change the target names to avoid clashes with system installations of 
LUA.


For more info about #1 and #3 please look at my other mails in this same 
thread. For #5 see 'target names' thread.

Francesco

Hi,

k. holwerda ha scritto:
>> I like the two target names to be changed, since else i can not use 
>> them the same way with Cmake.
>> Actually it is more a VC project problem, cmake does generate them 
>> correctly.
>> The problem is that there is a lua executable and a lua library, and 
>> the same for wxlua.
>> Especially the lua itself is causing me problems, since that target is 
>> used to generate the binding too.
>> So it name should be lua(.exe)
>>
>> Can the library names  be changed to wxlual and lual ?
>>
>> ( i wonder anyway what happens if our internal lua is installed, and 
>> it conflicts with a lua lib installed form some other source. So it 
>> might not be a bad idea to name ours different. )
I agree we need to redefine the names of the libraries created by wxLua. 
  Specially to avoid conflicts with LUA libraries installed from other 
sources, if this is necessary.

So,
1) is the lua library compiled with wxLua different from the 
'standard/official' lua library ?
I think it is because I saw the symbol WXLUA_CODE defined when compiling 
lua...

2) how do we name the wxLua libraries ?
    Currently I see in wxLua/lib:

-rw-r--r--  1 frm frm   674700 2006-01-24 10:13 liblua.a
-rw-r--r--  1 frm frm   128872 2006-01-20 13:40 liblualib.a
-rw-r--r--  1 frm frm 13821610 2006-01-25 18:47 libwxbind.a
-rw-r--r--  1 frm frm  1706004 2006-01-24 10:14 libwxlua.a
-rw-r--r--  1 frm frm  1320170 2006-01-24 10:19 libwxluadebug.a
-rw-r--r--  1 frm frm  1812618 2006-01-24 10:19 libwxluasocket.a

but I know that John's hand written makefiles have a more wx-like 
library namings. We could name them as:

      libwxlua_[gtk2|x11|msw|...][u][d]_lua-[wxversion].so.0
      libwxlua_[gtk2|x11|msw|...][u][d]_lualib-[wxversion].so.0
      libwxlua_[gtk2|x11|msw|...][u][d]_wxbind-[wxversion].so.0
      libwxlua_[gtk2|x11|msw|...][u][d]_wxlua-[wxversion].so.0
      libwxlua_[gtk2|x11|msw|...][u][d]_wxluadebug-[wxversion].so.0
      libwxlua_[gtk2|x11|msw|...][u][d]_wxluasocket-[wxversion].so.0

Do you agree ?

Francesco

Hi,

John Labenski wrote:

>>So leafs the not found target.
>>
>>I see in the modules a split in sourse and headers, nice!
>>Can it be made non capital in all cases?
>>
>>In apps.dsw, i get can not open wxmsw27d_xrc.lib, indeed that i don't
>>have ;-)
>>I have wxmsw26d_xrc.lib, how come?
>>    
>>
>
>The last update using bakefile has changed from 26 to 27. I use
>wxWidgets CVS head so this is not a problem, but we should revert to
>26 since that is the stable brach of wxWidgets.
>  
>
I am suprized why it  is not recognized automatically using WXWIN?
All other are oke.

Anyway i changed it to 26 and after correcting all other problems, i did 
get an error in lua.
(wxStyledTextCtrl (a nil value ).

>  
>
>>How does one deal with stedit in the second target? Maybe that should go
>>into install.html too.
>>    
>>
>
>What second target?
>  
>
wxluaedit uses stedit, so the second target in that apps.dsw

>  
>
>>>Trying to test it.
>>>
>>>In the project file wxLua.dsw, VC6 could not find target app_wxLua, it
>>>seems to search for
>>>wxLua/apps/build/msw/apps.dsp.
>>>And indeed i could not find it, although there is apps.dsw.
>>>
>>>Can you fix that?
>>>      
>>>
>
>apps.dsp has been removed, do another checkout.
>  
>
I know that, but it is still referred to from wxLua.dsw.

I just did another checkout,

wxLua.dsw contains this line ( see apps.dsp ), which can not be found.

Project: "app_wxlua"=..\..\apps\build\msw\apps.dsp - Package Owner=<4>

And it is all LF again, so no project file works anymore.

Converting by hand back to CRLF makes apps.dsp the problem again.

Project: "apps_app_wxlua"=..\..\apps\build\msw\apps_app_wxlua.dsp - 
Package Owner=<4>
Project: 
"apps_app_wxluaedit"=..\..\apps\build\msw\apps_app_wxluaedit1.dsp - 
Package Owner=<4>

>  
>
>>>Is there already a cleanall /deep ?  I see that things get mixed up in
>>>project files, so a real good/all clean like in wxArt2D  is needed i
>>>think.
>>>      
>>>
>
>A clean checkout is probably best.
>  
>
No bettter copy that bakefile part from wxArt2D, it should be the same.
Then using the makefiles one can do a proper clean.

Klaas


Unclassified

On 1/24/06, klaas.holwerda <kho...@xs...> wrote:
> and in the others i see wxluasetup.h ?
>
> Generated the bindings once more, and no it is luasetup.h all over??
> I wonder what i did  do wrong?

It's called wxluasetup.h now.

> So leafs the not found target.
>
> I see in the modules a split in sourse and headers, nice!
> Can it be made non capital in all cases?
>
> In apps.dsw, i get can not open wxmsw27d_xrc.lib, indeed that i don't
> have ;-)
> I have wxmsw26d_xrc.lib, how come?

The last update using bakefile has changed from 26 to 27. I use
wxWidgets CVS head so this is not a problem, but we should revert to
26 since that is the stable brach of wxWidgets.

> How does one deal with stedit in the second target? Maybe that should go
> into install.html too.

What second target?

> > Trying to test it.
> >
> > In the project file wxLua.dsw, VC6 could not find target app_wxLua, it
> > seems to search for
> > wxLua/apps/build/msw/apps.dsp.
> > And indeed i could not find it, although there is apps.dsw.
> >
> > Can you fix that?

apps.dsp has been removed, do another checkout.

> > Is there already a cleanall /deep ?  I see that things get mixed up in
> > project files, so a real good/all clean like in wxArt2D  is needed i
> > think.

A clean checkout is probably best.

-John