wxlua-users Mailing List for wxLua (Page 160)

I wrote it, and I looked at it and had to think twice....
Generally,=20
1. create a ctags file
2. run ctag2dat - parses ctag file into a lua data file (ldat)
3. run dat2i - loads dat file and creates *.i files
4. run genwxbind.lua - reads *.i files and generates code
The .rule files configure parsing rules. A rule file can be written to
tell the scripts on what to ignore, hints etc
Steps 2 and 3 where written to generate new interfaces for 3rd party
libs. Not for generating wx inferface files. I am currently modifying
them to be able to extract wx interfaces.
Firstly I have have alreadly extracted all the hand coded wx
conditionals. I am now working on a little parser to extract conditional
compile macros (wxUSE_xxx) directly from wx headers. Once I have that I
can regenerate a complete set of interface files. This can be
automatically create new interfaces for each version. I was thinking of
moving all depreciated classes to their own wx version *.i file.
Ray
-----Original Message-----
From: wxl...@li...
[mailto:wxl...@li...] On Behalf Of John
Labenski
Sent: Wednesday, 15 June 2005 13:18
To: wxl...@li...
Subject: Re: [Wxlua-users] Bakefile
On 6/14/05, Francesco Montorsi <f18...@ya...> wrote:
> Hi,
> now wxLua bakefiles are in good state: you should be able to use=20
> them (from command-line) to build all modules & bin2c.
> I have some problem with apps\wxlua: when compiling with
>=20
> nmake -fmakefile.vc WX_UNICODE=3D1
From what dir?
> I get:
> Microsoft (R) Program Maintenance Utility Version 6.00.8168.0
> Copyright (C) Microsoft Corp 1988-1998. All rights reserved.
> ..\..\..\bin\lua -e"target=3D\"msw\"" =
..\..\wxlua\src\wrap.lua=20
> Finding wxWindows Path Using Environment Variable : =
WXWIN=3Dc:\wxWidgets
> Target is : msw Parsing wxWindows Version File:=20
> c:\wxWidgets/include/wx/version.h Parsing wxWindows Setup File:=20
> c:\wxWidgets/include/wx/msw/setup.h
> Setup: Compatibility For wxWindows Version 2.4 Output File:=20
> wxluawrap.cpp Parsing Lua Setup File: luasetup.h.in
> ..\..\..\bin\lua: ../../../bindings/wxluawrap.lua:1834: bad argument=20
> #1 to `line s' (No such file or directory) stack traceback:
> [C]: in function `lines'
> ../../../bindings/wxluawrap.lua:1834: in function
`ReadSetupFiles'
> ../../../bindings/wxluawrap.lua:1909: in function `main'
> ../../../bindings/wxluawrap.lua:3225: in main chunk
> [C]: in function `dofile'
> ..\..\wxlua\src\wrap.lua:11: in main chunk
> [C]: ?
> NMAKE : fatal error U1077: '..\..\..\bin\lua' : return code '0x1'
> Stop.
> NMAKE : fatal error U1077: '"C:\Programmi\Microsoft Visual=20
> Studio\VC98\bin\NMAKE .EXE"' : return code '0x2'
> Stop.
>=20
> I put that step (..\..\..\bin\lua -e"target=3D\"msw\""
> ..\..\wxlua\src\wrap.lua) looking at the DSP file... what am I missing
?
You need to make sure that the dirs are correct. We have to use all
relative paths so that if you're building in wxLua/build/msw you
probably have to have something like this.
First go to apps/wxlua/src dir then run wrap.bat (or directly call
wrap.lua as you do) then go back to build/msw.
cd ..\..\apps\wxlua\src && "wrap.bat" && cd ..\..\..\build\msw=20
> >> When you run bindings/wxluawrap.lua it takes either the=20
> >> luasetup.h.in the bindings dir or in your own program's dir and=20
> >> generates luasetup.h that may exclude other classes automatically
using their dependencies.
> >> It can be updated by hand. Please see apps/wxlua/wrap.bat/lua and=20
> >> Makefile_import to see how the wrappers are generated. It's build=20
> >> is also automated in apps/wxlua/src/wxlua_wx26.dsp running wrap.bat
> >> to generate wxluawrap.cpp, can bakefile do this sort of thing?
> as you can see from the output log above, I created a target in=20
> makefiles ("wrap") which calls the lua.exe file on=20
> apps/wxlua/src/wrap.lua... the only problem is that bakefile does not=20
> know how to build files with extension ".i" so I had to include in=20
> apps\wxlua sources the file bindings\wxwidgets\wxluawrap.c which the=20
> makefiles generate just copying the bindings\wxwidgets\wxluawrap.i=20
> file... this is the only problem I've found.
Don't spend too much time on this, we'll be using a whole different set
to wrappers soon.
Something like this, where we can build a lib out of it or just include
them in your project.
=20
http://cvs.sourceforge.net/viewcvs.py/wxstudio/wxIDE/parts/cdlua/wxbind/
I'm having a hard time understanding the code to do it though.
-John Labenski
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id=16492&op=3Dick
_______________________________________________
Wxlua-users mailing list
Wxl...@li...
https://lists.sourceforge.net/lists/listinfo/wxlua-users

On 6/13/05, Ray Gilbert <ray...@sc...> wrote:
> Last night I cvs to wxIDE the latest wxXmlRpc, DebuggerNub, cdLua files
> so you may want to update them as well.
>=20
> I can now run cdLua.exe as an external process of wxStudio and debug the
> lua script. The debugger can show callstack, global and local variables.
I'm still having a hard time compiling wxIDE using your "Debug" which
I think is really Debug DLL, right? I compiled wxWidgets as Debug and
Debug DLL (non unicode) and can compile a wxWidgets sample w/o problem
though when I run it I get an error saying that it can't find the DLL,
do I really have to copy them to my windows/system dir? I've never
compiled wxWidgets as a DLL before, always static lib in MSW.
I have the environment variable WXWIN set properly and use it for my
own programs. I'm using VC6 on WinXP using build/msw/CodeDragon.dsw in
Batch Build. Could you tell me exactly what settings you use to
compile wxWidgets and wxIDE so I can try those?
Here are some of the (hundreds of) errors I get
C:\wxCVS\wxIDE\wxIDE\parts\thread\src\threadmanager.cpp(43): Could not
find the file sys/time.h.
c:\wxCVS\wxWidgets\include\wx\defs.h(2297): Could not find the file unistd.=
h.
c:\wxCVS\wxWidgets\include\wx\wxchar.h(107): Could not find the file wcstr.=
h.
c:\wxCVS\wxWidgets\include\wx\string.h(47): Could not find the file strings=
.h.
c:\wxCVS\wxWidgets\include\wx\string.h(51): Could not find the file StringM=
gr.h.
c:\wxCVS\wxWidgets\include\wx\utils.h(41): Could not find the file dirent.h=
.
c:\wxCVS\wxWidgets\include\wx\utils.h(42): Could not find the file unistd.h=
.
c:\wxCVS\wxWidgets\include\wx\platform.h(37): Could not find the file unist=
d.h.
c:\wxCVS\wxWidgets\include\wx\platform.h(515): Could not find the file Palm=
OS.h.
=20
They're bizarre, how the heck is it getting here?! WXPALMOS is defined
nowhere as far as I can tell, not in
$(WXWIN)/lib/vc_dll/mswd/include/wx/setup.h at least. Like I said I
get no errors or warnings whatsoever compiling a wxWidget's sample.
#ifdef __WXPALMOS__
# include <PalmOS.h> -- platform.h line 515
# undef Abs
#endif
> I am now working on a set of lua scripts to merge new wxWidget versions
> - so it can pick up new wx classes, merge new members automatically.
> This will save lots of time as new wx versions are released.
Sounds good, but first... I found that none of the enums are being
written to the wrapper.cpp files. I traced though genwxbind.lua the
best I could and didn't see any difference between the "enum" handling
and the "define" handling, but I haven't started to really debug it.
I'm slowly merging them, I'll try to get it working by the end of the
week, but I'd like to see what wxIDE looks like to get a better
understanding of it.
-John Labenski
> -----Original Message-----
> From: wxl...@li...
> [mailto:wxl...@li...] On Behalf Of John
> Labenski
> Sent: Tuesday, 14 June 2005 03:32
> To: wxl...@li...
> Subject: Re: [Wxlua-users] Bakefile
>=20
> Thanks for all your work.
>=20
> I'm slowly merging wxIDE's cdlua's code and wrappers, but it's slow
> going. I hope to have it done be the end of the week and then everyone
> can just use this version of wxLua.
>=20
> Regards,
> John Labenski
>=20
> On 6/12/05, Francesco Montorsi <f18...@ya...> wrote:
> > Hi,
> >
> > >>1) I see wxLua\src & wxLua\include are not listed in dirs.txt;
> > >>should they be removed ?
> > > Yes, but let's leave them for now since they still have one file in
> > > them that Ray says he doesn't want, but it probably wouldn't hurt to
>=20
> > > let it be for a bit.
> > ok, no problem
> >
> >
> > >>2) The targets which need to be built are:
> > >>- modules\lua
> > >>- modules\wxlua
> > >>- modules\wxluadebug
> > >>- modules\wxluasocket
> > >
> > > for modules/lua you need to build two things, lua.exe the lua
> > > executable and lua.lib the library. lua should be built as a static
> > > lib on all platforms, see the Makefiles and dsp files to see how
> > > it's done.
> > > Maybe you can take a look at these bakefiles to see if they'll work
> > > for us http://lua-users.org/wiki/LuaAddons
> > > http://www.geocities.com/f18m_cpp217828/prog/lua_win32.zip
> > yes, they'll work for us since I created them and uploaded the links
> > above in lua wiki & on my website ;-)
> >
> > >>Do they support shared (i.e. DLL) builds ?
> > > Hopefully yes, I've never build wxWidgets as a DLL, but I copied the
>=20
> > > code in the wxWidget's contrib and added WXDLLIMPEXP_WXLUA which
> > > should export things properly. I have no idea about lua itself
> though.
> > ok, I'll try
> >
> >
> > >>All the output should go to wxArt2d\lib, right ?
> > > No? It goes to wxLua/lib for the libraries and lua.exe goes to
> > > wxLua/bin this is a standalone library that anyone can use.
> > oops; I just meant wxLua/lib & wxLua/bin... sorry
> >
> > >>Its output should go to wxArt2d\bin, right ?
> > >
> > > No, it should be built in either wxLua/bin or just
> > > wxLua/apps/wxlua/src/vc_xxx for VC for example, in much the same way
>=20
> > > wxWidgets builds it's samples.
> > again I mistyped the path...
> >
> >
> > >>4) in wxLua\bindings\wxwidgets there are some CPP & H files; should
> > >>they be built as a library ?
> > >>If yes, how should that lib be called ?
> > >
> > > No, for now they're included directly into the wrappers which is
> > > probably the simplest solution for now. Thew whole wrapper thing is
> > > going to change somehow...
> > ok
> >
> > > Maybe we could put apps/wxlua/build into just apps/build to simplify
> things.
> > right, that makes things more simmetric :-)
> >
> > >>to build the project, the user should just go to wxlua\build\msw and
>=20
> > >>type
> > >>
> > >>nmake -fmakefile.vc WX_UNICODE=3D0/1 WX_SHARED=3D0/1 ....
> > >
> > >
> > > That would be great, maybe we could also have a dsw file as well,
> > > see apps/wxlua/src/wxLua.dsw that can build all the libraries using
> > > "batch build" just like wx.dsw.
> > sure; exactly like wxWidgets also have DSW/DSP files.
> >
> > >>PS: I see that exists a file called luasetup.h in
> > >>wxlua\bindings\wxwidgets; what is its use ? should it be generated
> > >>by some tool/makefile ?
> > > When you run bindings/wxluawrap.lua it takes either the
> > > luasetup.h.in the bindings dir or in your own program's dir and
> > > generates luasetup.h that may exclude other classes automatically
> using their dependencies.
> > > It can be updated by hand. Please see apps/wxlua/wrap.bat/lua and
> > > Makefile_import to see how the wrappers are generated. It's build is
>=20
> > > also automated in apps/wxlua/src/wxlua_wx26.dsp running wrap.bat to
> > > generate wxluawrap.cpp, can bakefile do this sort of thing?
> > yes, it can; I'll set up all this stuff when done with modules
> > bakefile; first I'll create modules\build stuff...
> >
> > I'll let you know,
> > Francesco
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: NEC IT Guy Games. How far can you
> > shotput a projector? How fast can you ride your desk chair down the
> office luge track?
> > If you want to score the big prize, get to know the little guy.
> > Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=3D20
> > _______________________________________________
> > Wxlua-users mailing list
> > Wxl...@li...
> > https://lists.sourceforge.net/lists/listinfo/wxlua-users
> >
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games. How far can you
> shotput a projector? How fast can you ride your desk chair down the
> office luge track?
> If you want to score the big prize, get to know the little guy.
> Play to win an NEC 61" plasma display: http://www.necitguy.com/?r
> _______________________________________________
> Wxlua-users mailing list
> Wxl...@li...
> https://lists.sourceforge.net/lists/listinfo/wxlua-users
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games. How far can you sho=
tput
> a projector? How fast can you ride your desk chair down the office luge t=
rack?
> If you want to score the big prize, get to know the little guy.
> Play to win an NEC 61" plasma display: http://www.necitguy.com/?r
> _______________________________________________
> Wxlua-users mailing list
> Wxl...@li...
> https://lists.sourceforge.net/lists/listinfo/wxlua-users
>

On 6/14/05, Francesco Montorsi <f18...@ya...> wrote:
> Hi,
> now wxLua bakefiles are in good state: you should be able to use them
> (from command-line) to build all modules & bin2c.
> I have some problem with apps\wxlua: when compiling with
>=20
> nmake -fmakefile.vc WX_UNICODE=3D1
From what dir?
> I get:
> Microsoft (R) Program Maintenance Utility Version 6.00.8168.0
> Copyright (C) Microsoft Corp 1988-1998. All rights reserved.
> ..\..\..\bin\lua -e"target=3D\"msw\"" ..\..\wxlua\src\wrap.lua
> Finding wxWindows Path Using Environment Variable : WXWIN=3Dc:\wxWidgets
> Target is : msw
> Parsing wxWindows Version File: c:\wxWidgets/include/wx/version.h
> Parsing wxWindows Setup File: c:\wxWidgets/include/wx/msw/setup.h
> Setup: Compatibility For wxWindows Version 2.4
> Output File: wxluawrap.cpp
> Parsing Lua Setup File: luasetup.h.in
> ..\..\..\bin\lua: ../../../bindings/wxluawrap.lua:1834: bad argument #1
> to `line
> s' (No such file or directory)
> stack traceback:
> [C]: in function `lines'
> ../../../bindings/wxluawrap.lua:1834: in function `ReadSetupFile=
s'
> ../../../bindings/wxluawrap.lua:1909: in function `main'
> ../../../bindings/wxluawrap.lua:3225: in main chunk
> [C]: in function `dofile'
> ..\..\wxlua\src\wrap.lua:11: in main chunk
> [C]: ?
> NMAKE : fatal error U1077: '..\..\..\bin\lua' : return code '0x1'
> Stop.
> NMAKE : fatal error U1077: '"C:\Programmi\Microsoft Visual
> Studio\VC98\bin\NMAKE
> .EXE"' : return code '0x2'
> Stop.
>=20
> I put that step (..\..\..\bin\lua -e"target=3D\"msw\""
> ..\..\wxlua\src\wrap.lua) looking at the DSP file... what am I missing ?
You need to make sure that the dirs are correct. We have to use all
relative paths so that if you're building in wxLua/build/msw you
probably have to have something like this.
First go to apps/wxlua/src dir then run wrap.bat (or directly call
wrap.lua as you do) then go back to build/msw.
cd ..\..\apps\wxlua\src && "wrap.bat" && cd ..\..\..\build\msw=20
> >> When you run bindings/wxluawrap.lua it takes either the luasetup.h.in
> >> the bindings dir or in your own program's dir and generates luasetup.h
> >> that may exclude other classes automatically using their dependencies.
> >> It can be updated by hand. Please see apps/wxlua/wrap.bat/lua and
> >> Makefile_import to see how the wrappers are generated. It's build is
> >> also automated in apps/wxlua/src/wxlua_wx26.dsp running wrap.bat to
> >> generate wxluawrap.cpp, can bakefile do this sort of thing?
> as you can see from the output log above, I created a target in
> makefiles ("wrap") which calls the lua.exe file on
> apps/wxlua/src/wrap.lua... the only problem is that bakefile does not
> know how to build files with extension ".i" so I had to include in
> apps\wxlua sources the file bindings\wxwidgets\wxluawrap.c which the
> makefiles generate just copying the bindings\wxwidgets\wxluawrap.i
> file... this is the only problem I've found.
Don't spend too much time on this, we'll be using a whole different
set to wrappers soon.
Something like this, where we can build a lib out of it or just
include them in your project.
 http://cvs.sourceforge.net/viewcvs.py/wxstudio/wxIDE/parts/cdlua/wxbind/
I'm having a hard time understanding the code to do it though.
-John Labenski

Hi,
 now wxLua bakefiles are in good state: you should be able to use them 
(from command-line) to build all modules & bin2c.
I have some problem with apps\wxlua: when compiling with
nmake -fmakefile.vc WX_UNICODE=1
I get:
Microsoft (R) Program Maintenance Utility Version 6.00.8168.0
Copyright (C) Microsoft Corp 1988-1998. All rights reserved.
 ..\..\..\bin\lua -e"target=\"msw\"" ..\..\wxlua\src\wrap.lua
Finding wxWindows Path Using Environment Variable : WXWIN=c:\wxWidgets
Target is : msw
Parsing wxWindows Version File: c:\wxWidgets/include/wx/version.h
Parsing wxWindows Setup File: c:\wxWidgets/include/wx/msw/setup.h
Setup: Compatibility For wxWindows Version 2.4
Output File: wxluawrap.cpp
Parsing Lua Setup File: luasetup.h.in
..\..\..\bin\lua: ../../../bindings/wxluawrap.lua:1834: bad argument #1 
to `line
s' (No such file or directory)
stack traceback:
 [C]: in function `lines'
 ../../../bindings/wxluawrap.lua:1834: in function `ReadSetupFiles'
 ../../../bindings/wxluawrap.lua:1909: in function `main'
 ../../../bindings/wxluawrap.lua:3225: in main chunk
 [C]: in function `dofile'
 ..\..\wxlua\src\wrap.lua:11: in main chunk
 [C]: ?
NMAKE : fatal error U1077: '..\..\..\bin\lua' : return code '0x1'
Stop.
NMAKE : fatal error U1077: '"C:\Programmi\Microsoft Visual 
Studio\VC98\bin\NMAKE
.EXE"' : return code '0x2'
Stop.
I put that step (..\..\..\bin\lua -e"target=\"msw\"" 
..\..\wxlua\src\wrap.lua) looking at the DSP file... what am I missing ?
>> When you run bindings/wxluawrap.lua it takes either the luasetup.h.in
>> the bindings dir or in your own program's dir and generates luasetup.h
>> that may exclude other classes automatically using their dependencies.
>> It can be updated by hand. Please see apps/wxlua/wrap.bat/lua and
>> Makefile_import to see how the wrappers are generated. It's build is
>> also automated in apps/wxlua/src/wxlua_wx26.dsp running wrap.bat to
>> generate wxluawrap.cpp, can bakefile do this sort of thing?
as you can see from the output log above, I created a target in 
makefiles ("wrap") which calls the lua.exe file on 
apps/wxlua/src/wrap.lua... the only problem is that bakefile does not 
know how to build files with extension ".i" so I had to include in 
apps\wxlua sources the file bindings\wxwidgets\wxluawrap.c which the 
makefiles generate just copying the bindings\wxwidgets\wxluawrap.i 
file... this is the only problem I've found.
Let me know,
Francesco

Last night I cvs to wxIDE the latest wxXmlRpc, DebuggerNub, cdLua files
so you may want to update them as well.
I can now run cdLua.exe as an external process of wxStudio and debug the
lua script. The debugger can show callstack, global and local variables.
I am now working on a set of lua scripts to merge new wxWidget versions
- so it can pick up new wx classes, merge new members automatically.
This will save lots of time as new wx versions are released.
Ray
-----Original Message-----
From: wxl...@li...
[mailto:wxl...@li...] On Behalf Of John
Labenski
Sent: Tuesday, 14 June 2005 03:32
To: wxl...@li...
Subject: Re: [Wxlua-users] Bakefile
Thanks for all your work.=20
I'm slowly merging wxIDE's cdlua's code and wrappers, but it's slow
going. I hope to have it done be the end of the week and then everyone
can just use this version of wxLua.
Regards,
 John Labenski
On 6/12/05, Francesco Montorsi <f18...@ya...> wrote:
> Hi,
>=20
> >>1) I see wxLua\src & wxLua\include are not listed in dirs.txt;=20
> >>should they be removed ?
> > Yes, but let's leave them for now since they still have one file in=20
> > them that Ray says he doesn't want, but it probably wouldn't hurt to
> > let it be for a bit.
> ok, no problem
>=20
>=20
> >>2) The targets which need to be built are:
> >>- modules\lua
> >>- modules\wxlua
> >>- modules\wxluadebug
> >>- modules\wxluasocket
> >
> > for modules/lua you need to build two things, lua.exe the lua=20
> > executable and lua.lib the library. lua should be built as a static=20
> > lib on all platforms, see the Makefiles and dsp files to see how=20
> > it's done.
> > Maybe you can take a look at these bakefiles to see if they'll work=20
> > for us http://lua-users.org/wiki/LuaAddons
> > http://www.geocities.com/f18m_cpp217828/prog/lua_win32.zip
> yes, they'll work for us since I created them and uploaded the links=20
> above in lua wiki & on my website ;-)
>=20
> >>Do they support shared (i.e. DLL) builds ?
> > Hopefully yes, I've never build wxWidgets as a DLL, but I copied the
> > code in the wxWidget's contrib and added WXDLLIMPEXP_WXLUA which=20
> > should export things properly. I have no idea about lua itself
though.
> ok, I'll try
>=20
>=20
> >>All the output should go to wxArt2d\lib, right ?
> > No? It goes to wxLua/lib for the libraries and lua.exe goes to=20
> > wxLua/bin this is a standalone library that anyone can use.
> oops; I just meant wxLua/lib & wxLua/bin... sorry
>=20
> >>Its output should go to wxArt2d\bin, right ?
> >
> > No, it should be built in either wxLua/bin or just=20
> > wxLua/apps/wxlua/src/vc_xxx for VC for example, in much the same way
> > wxWidgets builds it's samples.
> again I mistyped the path...
>=20
>=20
> >>4) in wxLua\bindings\wxwidgets there are some CPP & H files; should=20
> >>they be built as a library ?
> >>If yes, how should that lib be called ?
> >
> > No, for now they're included directly into the wrappers which is=20
> > probably the simplest solution for now. Thew whole wrapper thing is=20
> > going to change somehow...
> ok
>=20
> > Maybe we could put apps/wxlua/build into just apps/build to simplify
things.
> right, that makes things more simmetric :-)
>=20
> >>to build the project, the user should just go to wxlua\build\msw and
> >>type
> >>
> >>nmake -fmakefile.vc WX_UNICODE=3D0/1 WX_SHARED=3D0/1 ....
> >
> >
> > That would be great, maybe we could also have a dsw file as well,=20
> > see apps/wxlua/src/wxLua.dsw that can build all the libraries using=20
> > "batch build" just like wx.dsw.
> sure; exactly like wxWidgets also have DSW/DSP files.
>=20
> >>PS: I see that exists a file called luasetup.h in=20
> >>wxlua\bindings\wxwidgets; what is its use ? should it be generated=20
> >>by some tool/makefile ?
> > When you run bindings/wxluawrap.lua it takes either the=20
> > luasetup.h.in the bindings dir or in your own program's dir and=20
> > generates luasetup.h that may exclude other classes automatically
using their dependencies.
> > It can be updated by hand. Please see apps/wxlua/wrap.bat/lua and=20
> > Makefile_import to see how the wrappers are generated. It's build is
> > also automated in apps/wxlua/src/wxlua_wx26.dsp running wrap.bat to=20
> > generate wxluawrap.cpp, can bakefile do this sort of thing?
> yes, it can; I'll set up all this stuff when done with modules=20
> bakefile; first I'll create modules\build stuff...
>=20
> I'll let you know,
> Francesco
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games. How far can you=20
> shotput a projector? How fast can you ride your desk chair down the
office luge track?
> If you want to score the big prize, get to know the little guy.
> Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=3D20 =
> _______________________________________________
> Wxlua-users mailing list
> Wxl...@li...
> https://lists.sourceforge.net/lists/listinfo/wxlua-users
>
-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games. How far can you
shotput a projector? How fast can you ride your desk chair down the
office luge track?
If you want to score the big prize, get to know the little guy. =20
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r
_______________________________________________
Wxlua-users mailing list
Wxl...@li...
https://lists.sourceforge.net/lists/listinfo/wxlua-users

Thanks for all your work.=20
I'm slowly merging wxIDE's cdlua's code and wrappers, but it's slow
going. I hope to have it done be the end of the week and then everyone
can just use this version of wxLua.
Regards,
 John Labenski
On 6/12/05, Francesco Montorsi <f18...@ya...> wrote:
> Hi,
>=20
> >>1) I see wxLua\src & wxLua\include are not listed in dirs.txt; should
> >>they be removed ?
> > Yes, but let's leave them for now since they still have one file in
> > them that Ray says he doesn't want, but it probably wouldn't hurt to
> > let it be for a bit.
> ok, no problem
>=20
>=20
> >>2) The targets which need to be built are:
> >>- modules\lua
> >>- modules\wxlua
> >>- modules\wxluadebug
> >>- modules\wxluasocket
> >
> > for modules/lua you need to build two things, lua.exe the lua
> > executable and lua.lib the library. lua should be built as a static
> > lib on all platforms, see the Makefiles and dsp files to see how it's
> > done.
> > Maybe you can take a look at these bakefiles to see if they'll work for=
 us
> > http://lua-users.org/wiki/LuaAddons
> > http://www.geocities.com/f18m_cpp217828/prog/lua_win32.zip
> yes, they'll work for us since I created them and uploaded the links
> above in lua wiki & on my website ;-)
>=20
> >>Do they support shared (i.e. DLL) builds ?
> > Hopefully yes, I've never build wxWidgets as a DLL, but I copied the
> > code in the wxWidget's contrib and added WXDLLIMPEXP_WXLUA which
> > should export things properly. I have no idea about lua itself though.
> ok, I'll try
>=20
>=20
> >>All the output should go to wxArt2d\lib, right ?
> > No? It goes to wxLua/lib for the libraries and lua.exe goes to
> > wxLua/bin this is a standalone library that anyone can use.
> oops; I just meant wxLua/lib & wxLua/bin... sorry
>=20
> >>Its output should go to wxArt2d\bin, right ?
> >
> > No, it should be built in either wxLua/bin or just
> > wxLua/apps/wxlua/src/vc_xxx for VC for example, in much the same way
> > wxWidgets builds it's samples.
> again I mistyped the path...
>=20
>=20
> >>4) in wxLua\bindings\wxwidgets there are some CPP & H files; should the=
y
> >>be built as a library ?
> >>If yes, how should that lib be called ?
> >
> > No, for now they're included directly into the wrappers which is
> > probably the simplest solution for now. Thew whole wrapper thing is
> > going to change somehow...
> ok
>=20
> > Maybe we could put apps/wxlua/build into just apps/build to simplify th=
ings.
> right, that makes things more simmetric :-)
>=20
> >>to build the project, the user should just go to wxlua\build\msw and ty=
pe
> >>
> >>nmake -fmakefile.vc WX_UNICODE=3D0/1 WX_SHARED=3D0/1 ....
> >
> >
> > That would be great, maybe we could also have a dsw file as well, see
> > apps/wxlua/src/wxLua.dsw that can build all the libraries using "batch
> > build" just like wx.dsw.
> sure; exactly like wxWidgets also have DSW/DSP files.
>=20
> >>PS: I see that exists a file called luasetup.h in
> >>wxlua\bindings\wxwidgets; what is its use ? should it be generated by
> >>some tool/makefile ?
> > When you run bindings/wxluawrap.lua it takes either the luasetup.h.in
> > the bindings dir or in your own program's dir and generates luasetup.h
> > that may exclude other classes automatically using their dependencies.
> > It can be updated by hand. Please see apps/wxlua/wrap.bat/lua and
> > Makefile_import to see how the wrappers are generated. It's build is
> > also automated in apps/wxlua/src/wxlua_wx26.dsp running wrap.bat to
> > generate wxluawrap.cpp, can bakefile do this sort of thing?
> yes, it can; I'll set up all this stuff when done with modules bakefile;
> first I'll create modules\build stuff...
>=20
> I'll let you know,
> Francesco
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games. How far can you sho=
tput
> a projector? How fast can you ride your desk chair down the office luge t=
rack?
> If you want to score the big prize, get to know the little guy.
> Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=3D20
> _______________________________________________
> Wxlua-users mailing list
> Wxl...@li...
> https://lists.sourceforge.net/lists/listinfo/wxlua-users
>

Hi,
>>1) I see wxLua\src & wxLua\include are not listed in dirs.txt; should
>>they be removed ?
> Yes, but let's leave them for now since they still have one file in
> them that Ray says he doesn't want, but it probably wouldn't hurt to
> let it be for a bit.
ok, no problem
>>2) The targets which need to be built are:
>>- modules\lua
>>- modules\wxlua
>>- modules\wxluadebug
>>- modules\wxluasocket
> 
> for modules/lua you need to build two things, lua.exe the lua
> executable and lua.lib the library. lua should be built as a static
> lib on all platforms, see the Makefiles and dsp files to see how it's
> done.
> Maybe you can take a look at these bakefiles to see if they'll work for us
> http://lua-users.org/wiki/LuaAddons
> http://www.geocities.com/f18m_cpp217828/prog/lua_win32.zip
yes, they'll work for us since I created them and uploaded the links 
above in lua wiki & on my website ;-)
>>Do they support shared (i.e. DLL) builds ?
> Hopefully yes, I've never build wxWidgets as a DLL, but I copied the
> code in the wxWidget's contrib and added WXDLLIMPEXP_WXLUA which
> should export things properly. I have no idea about lua itself though.
ok, I'll try
>>All the output should go to wxArt2d\lib, right ?
> No? It goes to wxLua/lib for the libraries and lua.exe goes to
> wxLua/bin this is a standalone library that anyone can use.
oops; I just meant wxLua/lib & wxLua/bin... sorry
>>Its output should go to wxArt2d\bin, right ?
> 
> No, it should be built in either wxLua/bin or just
> wxLua/apps/wxlua/src/vc_xxx for VC for example, in much the same way
> wxWidgets builds it's samples.
again I mistyped the path...
>>4) in wxLua\bindings\wxwidgets there are some CPP & H files; should they
>>be built as a library ?
>>If yes, how should that lib be called ?
> 
> No, for now they're included directly into the wrappers which is
> probably the simplest solution for now. Thew whole wrapper thing is
> going to change somehow...
ok
> Maybe we could put apps/wxlua/build into just apps/build to simplify things.
right, that makes things more simmetric :-)
>>to build the project, the user should just go to wxlua\build\msw and type
>>
>>nmake -fmakefile.vc WX_UNICODE=0/1 WX_SHARED=0/1 ....
> 
> 
> That would be great, maybe we could also have a dsw file as well, see
> apps/wxlua/src/wxLua.dsw that can build all the libraries using "batch
> build" just like wx.dsw.
sure; exactly like wxWidgets also have DSW/DSP files.
>>PS: I see that exists a file called luasetup.h in
>>wxlua\bindings\wxwidgets; what is its use ? should it be generated by
>>some tool/makefile ?
> When you run bindings/wxluawrap.lua it takes either the luasetup.h.in
> the bindings dir or in your own program's dir and generates luasetup.h
> that may exclude other classes automatically using their dependencies.
> It can be updated by hand. Please see apps/wxlua/wrap.bat/lua and
> Makefile_import to see how the wrappers are generated. It's build is
> also automated in apps/wxlua/src/wxlua_wx26.dsp running wrap.bat to
> generate wxluawrap.cpp, can bakefile do this sort of thing?
yes, it can; I'll set up all this stuff when done with modules bakefile; 
first I'll create modules\build stuff...
I'll let you know,
Francesco

On 6/11/05, Francesco Montorsi <f18...@ya...> wrote:
> > Thanks, see the last message of mine called "Dir structure".
> I'm looking at my just-checked out wxLua module and I have some questions=
...
>=20
> 1) I see wxLua\src & wxLua\include are not listed in dirs.txt; should
> they be removed ?
Yes, but let's leave them for now since they still have one file in
them that Ray says he doesn't want, but it probably wouldn't hurt to
let it be for a bit.
=20
> 2) The targets which need to be built are:
> - modules\lua
> - modules\wxlua
> - modules\wxluadebug
> - modules\wxluasocket
for modules/lua you need to build two things, lua.exe the lua
executable and lua.lib the library. lua should be built as a static
lib on all platforms, see the Makefiles and dsp files to see how it's
done.
Maybe you can take a look at these bakefiles to see if they'll work for us
http://lua-users.org/wiki/LuaAddons
http://www.geocities.com/f18m_cpp217828/prog/lua_win32.zip
> and they must be built as libraries, right ?
Yes.
> Do they support shared (i.e. DLL) builds ?
Hopefully yes, I've never build wxWidgets as a DLL, but I copied the
code in the wxWidget's contrib and added WXDLLIMPEXP_WXLUA which
should export things properly. I have no idea about lua itself though.
> Do they support Unicode builds ?
Yes, all except lua.
> Except for lua, all others are wx-based, right ?
Yes, all Makefiles and wxXXX_wx26.dsp/w in the src/ dirs work properly
so you can get the proper include dirs and flags from them.
> All the output should go to wxArt2d\lib, right ?
No? It goes to wxLua/lib for the libraries and lua.exe goes to
wxLua/bin this is a standalone library that anyone can use.
> 3) the target wxLua\apps\wxlua does depend from all the modules listed
> in wxLua\modules ?
Yes.
> Does it supports shared & unicode builds ?
Yes.
> Its output should go to wxArt2d\bin, right ?
No, it should be built in either wxLua/bin or just
wxLua/apps/wxlua/src/vc_xxx for VC for example, in much the same way
wxWidgets builds it's samples.
> 4) in wxLua\bindings\wxwidgets there are some CPP & H files; should they
> be built as a library ?
> If yes, how should that lib be called ?
No, for now they're included directly into the wrappers which is
probably the simplest solution for now. Thew whole wrapper thing is
going to change somehow...
> Assuming all replies are yes, I'd organize bakefile build system as follo=
w:
>=20
> wxLua
> |-build
> | |- msw
> | |- bakefiles
> |
> |-modules
> | |-build
> | |- msw
> | |- bakefiles
> |
> |-apps
> | |-build
> | | |- msw
> | | |- bakefiles
> | |-wxlua
> | |-build
> | |- msw
> | |- bakefiles
> |
> |-utils
> | |-build
> | |- msw
> | |- bakefiles
Maybe we could put apps/wxlua/build into just apps/build to simplify things=
.
> to build the project, the user should just go to wxlua\build\msw and type
>=20
> nmake -fmakefile.vc WX_UNICODE=3D0/1 WX_SHARED=3D0/1 ....
That would be great, maybe we could also have a dsw file as well, see
apps/wxlua/src/wxLua.dsw that can build all the libraries using "batch
build" just like wx.dsw.
> Do you like this approach ?
It's be great if you can get it working.
> Let me know,
> Francesco Montorsi
>=20
> PS: I see that exists a file called luasetup.h in
> wxlua\bindings\wxwidgets; what is its use ? should it be generated by
> some tool/makefile ?
When you run bindings/wxluawrap.lua it takes either the luasetup.h.in
the bindings dir or in your own program's dir and generates luasetup.h
that may exclude other classes automatically using their dependencies.
It can be updated by hand. Please see apps/wxlua/wrap.bat/lua and
Makefile_import to see how the wrappers are generated. It's build is
also automated in apps/wxlua/src/wxlua_wx26.dsp running wrap.bat to
generate wxluawrap.cpp, can bakefile do this sort of thing?
> PS2: does wxLua builds in linux ?
Yup, using the makefiles that use wx-config.
>PS3: please fix the reply-to behaviour of this list: I really do not
>understand why mailman software sets to default the reply-to field to
>the sender of the mail instead of the mailing list itself !
It's fixed now, but the after the message you responded to. Any new
messages from now on should have the correct reply to. Thanks, Klaas.

Hi,
 > Thanks, see the last message of mine called "Dir structure".
I'm looking at my just-checked out wxLua module and I have some questions...
1) I see wxLua\src & wxLua\include are not listed in dirs.txt; should 
they be removed ?
2) The targets which need to be built are:
- modules\lua
- modules\wxlua
- modules\wxluadebug
- modules\wxluasocket
and they must be built as libraries, right ?
Do they support shared (i.e. DLL) builds ?
Do they support Unicode builds ?
Except for lua, all others are wx-based, right ?
All the output should go to wxArt2d\lib, right ?
3) the target wxLua\apps\wxlua does depend from all the modules listed 
in wxLua\modules ?
Does it supports shared & unicode builds ?
Its output should go to wxArt2d\bin, right ?
4) in wxLua\bindings\wxwidgets there are some CPP & H files; should they 
be built as a library ?
If yes, how should that lib be called ?
Assuming all replies are yes, I'd organize bakefile build system as follow:
wxLua
|-build
| |- msw
| |- bakefiles
|
|-modules
| |-build
| |- msw
| |- bakefiles
|
|-apps
| |-build
| | |- msw
| | |- bakefiles
| |-wxlua
| |-build
| |- msw
| |- bakefiles
|
|-utils
| |-build
| |- msw
| |- bakefiles
to build the project, the user should just go to wxlua\build\msw and type
nmake -fmakefile.vc WX_UNICODE=0/1 WX_SHARED=0/1 ....
Do you like this approach ?
Let me know,
Francesco Montorsi
PS: I see that exists a file called luasetup.h in 
wxlua\bindings\wxwidgets; what is its use ? should it be generated by 
some tool/makefile ?
PS2: does wxLua builds in linux ?
PS3: please fix the reply-to behaviour of this list: I really do not 
understand why mailman software sets to default the reply-to field to 
the sender of the mail instead of the mailing list itself !

John Labenski wrote:
>It now compiles in VC6. I've added my temporary dsp files named
>xxx_wx26 so you can try it if you like. 
>
Soon.
>
>ps. How do you remove directories from SF's CVS? Do you have to send a
>request for them to do it?
> 
>
I had the same problem. The solution is to remove all file which are in 
the dir.
Next update -P and the directory is not there anymore.
Of course the dir is still in CVS, but its not checked out anymore.
I think that is why one uses a dummy file to have a directory without files.
Klaas

It now compiles in VC6. I've added my temporary dsp files named
xxx_wx26 so you can try it if you like. You need only open the
apps/wxlua/src/wxlua_wx26.dsw to compile everything, but all the bits
have their own xxx_wx26.dsp file in their src dir.
Regards,
 John Labenski
ps. How do you remove directories from SF's CVS? Do you have to send a
request for them to do it?

I've moved the files to the new structure, supposing that it was
suitable for everyone. It currently builds cleanly in linux using
wxWidgets 2.6. I have not moved or modified my xxx_wx26.dsp VC6
project files or tested it in msw.
Currently we're still using the wrapper method where a giant
wxluawrap.cpp file is generated in the src directory of any program
using it. I've decided to move wxLuaPrinting/HtmlWindow into the
wrapper directory and added %inlinefile to the wxluawrap.lua. This tag
will directly include the given file "as is." It works nicely for
these two files since all they do is provide a means to use c++
virtual functions in lua for specific classes. I cannot think of any
reason why a user would want to include their headers. They're also
trivially small compared to the wrapper file itself, so they don't add
much more bloat over what we've already got.
I've broken the library into three parts:
wxlua - the base and this should be able to be used as is (not currently th=
ough)
wxluadebug - a library for showing the stacktree and maybe other debug stuf=
f
 hopefully this can be made to only require wxlua.
wxluasocket - the socket library that the wxlua app uses, this
requires the above.
I've not added Rays stuff yet.
It's not done yet and you have to link them all together currently,
but this should be possible. Anyway, I hope that with a good build
system and some samples for testing people can make changes and easily
see if they've broken anything.
See wxLua/docs/dirs.txt for a description of how it's supposed to
work... You can compile wxLua by going into apps/wxlua/src and running
make (maybe twice, I'll have to see about that).
Francesco, I have given you cvs access, but let me get my project
files working and make sure it works in VC6 so when you test it you're
not struggling with build problems. I suggest that we keep the current
Makefiles since they're very readable and simple to maintain. I don't
think we need configure for now and it'll add unnecessary complexity.
Unless of course, it can be made to work out of the box.
Feel free to comment on the structure, positive or negative, we've got
to all be happy with this.
Regards,
 John Labenski

Hi,
 > This would be great, but! We gotta get the dir structure down first.
 > Wait for a message saying that it's done.
ok; I'm waiting ;-)
 > I want to hear some Yea/Nays about it before I go through the trouble
 > of moving things. If you'd rather have it differently please post your
 > own full dir structure, I'm open to anything so long as we agree. I'm
 > finding the little snippits hard to understand and want to see the
 > whole thing to understand it. I don't want to do anything until I hear
 > people say, "yes, I can live with that, go ahead and move things"
 > since it really is a pain.
ok, as I said earlier I advise to use lowercase filenames & dirnames.
I'm now going to read the mails about dir structure; I'll let you know 
something if I think the dir structure can be improved...
 >> My SF id is "frm" so if you grant me write permissions I'll commit to
 >> the CVS the bakefiles.
 >
 > You are part of wxArt2D? It would be ok to add you by me.
I'm currently contributing bakefiles to wxArt2d (and so I'm listed as 
wxart2d developer) since I'm going to use it in my projects :-)
Since wxLua is a wxArt2d dependency I'd like to have wxLua bakefilized, too.
 >> Which libraries should be created from which source files and where
 >> should the output go ?
 >> Which executables should be created ?
 >> Does wxLua supports unicode & shared builds ?
 >> Are there additional tasks which the build system should take on ?
 >
 > See newdirs.txt here. 
http://cvs.sourceforge.net/viewcvs.py/wxlua/wxLua/docs/
 >
 > I will update it once we figure out the dirs and describe what goes
 > where and how, so don't write anything based on it right now.
okay, just let me know when you have definitively set up everything.
Francesco Montorsi
PS: I would correct GNUMailman standard behaviour so that the "reply-to" 
field of all mails are set to wxl...@li... and not 
to the sender of the mail ;-)

Hi John,
I think this #1 looks good.
About the bindings and wrapping, oke too.
A soon a there is a flexible way to extend the default wxWidgets 
wrapping with the app or other library its wrappings, all will be oke. 
I imagine this will be by making it possible to registers groups ( one 
table per lib/app). Or maybe Ray already has something better.
I think we will be able to generate a wxluaXXX.lib in static and shared.
But all that is for later, since it has no impact on the structure as 
you say.
John Labenski wrote:
> ==============================
> 1.) Use a module approach
> /modules/
> /build/ - to have build files for all of this
> /lua/ -- lua itself
> /include/
> /src/
> /the rest of lua.../
> /wxlua/ - the wxlua library itself
> /include/ = internal.h, interp.h, library.h
> /src/ = internal.cpp, interp.cpp, library.cpp
> /wxluasocket/ - lua to cpp sockets (the current lua sockets)
> /include/ = debugio.h, socket.h /src/ = 
> debugio.cpp, socket.cpp
> /wxluadebug/ - mechanism for getting/showing info from lua
> /include/ = debug.h, stacktree, splittree
> /src/ = debug.cpp, stacktree, splittree
> /xmlrpc/ - is is a generic lib right? so don't prepend wxlua to 
> it?
> /include/ = ... Rays stuff
> /src/ = ... Rays stuff
> /debuggernub/ - this is a generic lib for xmlrpc? don't
> prepend wxlua to it
> /include/ = ... Rays stuff
> /src/ = ... Rays stuff
> /wxluadebugger/ - this depends on wxlua so prepend wxlua to it
> /include/ = ... Rays stuff
> /src/ = ... Rays stuff
>
> I think Klaas is suggesting that a user will set the include path to
> wxLua/modules and then in a cpp file do
> #include "wxlua/include/xxx.h" 
>
Exactly! And of course all other in a simular way like:
#include "wxluasocket/include/xxx.h"
#include "wxluadebug/include/xxx.h"
> I vote #1.
> 
>
Me too.
So i hope the others will respond quickly, so things can start ;-)
Regards,
Klaas

> There is no need to create build directories in each module/program.
Agreed.
=20
> Thirdparty can go or made shorter,
> I can imagine there will be other third party stuff, but not so
> important as lua. ( e.g. xmlprc )
> If there is a module directory, or all is right at the top is also not
> that important.
> But if putting all programs and modules and thridparty libs at the top,
> this might be confusing to users too.
> So it is actually to make things more clear to users to what is what.
> Keeping source and include files and import files inside a "module" is
> i think good.
> And for the include path, it can be a single one, if all #include's in
> the source code are relative to .../wxLua/module or
> in the othere case .../wxLua
I think I'm starting to agree about separating them, how about putting
all the c/c++ code into the "module" directory and forget the
"thirdparty" dir all together, see #1 below.
=20
> As you say, maybe module should be called import or bindings, and the
> lua core should go up one level.
I think bindings should go into their own dir to separate them,
grepping through them will be easier since you won't have to slog
through all the c++ code.
> But i don;t know if bindings is always only thata, or if it sometimes
> comes with extra C++ code or even lua scripts.
Yes there are the wxLuaPrinting, wxLuaHtmlWin for example, these are
necessary to make use of vitual c++ functions. I think we can even
#include these inline in the wrappers to simplify things. Perhaps
someday (not soon through) virtual functions could be implemented
differently, but I don't think this will imact the dir structure.
=20
> A more important point is the binding code, where will the result of
> import files be build too.
> It is a sort of prebuild step followed by the build of the c++ code.
> This is how i handled it in Cmake, (using the bat/lua and shell files,
> but defining it as a target to get the binding code ).
> I agree that when wxLua standalone uses all settings, and some other
> only a small set, this should be possible.
> I think it will be complicated without editing a setup file to tune
> this, unless we solve this runtime.
The only solution I can think of is making each project compile the
wrapper bindings to their own object files and link to them. This is
exactly what we do now with the wxLuaWrap.cpp file. We can also
provide build files to make a library of all the wrappers, this is
what the wxlua program itself will use and people can use it as well.
I think any individual project will have very different requirements
and we don't have a good handle on how to do this so lets leave it up
to them for now.
Bottom line, a user's program can either use the complete set of
wrappers and take advantage of the wxLua app's build files or use
their own build files to customize it.
> What if the total binding code is always generated, but that only
> specific sets can be registrated to an application?
I think it would be a good idea to be able to reduce the size of wxLua
when linked to another program. The wrappers are pretty hefty, but as
I said we'll be providing this option since this is what the wxLua app
will do.
> If the core and binding code are inside libraries, the code is only
> linked in when used ??
I think because the wrapper functions are stored in structs they won't
get stripped out by the linker.
> Why not generate the bindings in the build directory too. It is in fact
> a result of a prebuild step.
We'll probably end up with premade cpp bindings that you'll link to.
Ray has added wxUSE_XXX ifdefs in them so that they'll work no matter
how a user's wxWidgets is setup (in linux using configure or msw using
msw/setup.h)
Of course, it seems like there's no reason why you couldn't build your
own set of wrappers on the fly and put them wherever you like.
> For me the next would be fine. I think it contains all directories needed=
.
>
> We only need to discuss if some need to move up or down in hierarchy.
> If you think it is better to move all in module and/or apps and /or
> thirdparty up one level, that is oke with me.
Ok, I prefer #1, but I left in #2 as the "other way" of doing it.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
The two schemes both share these dirs
wxLua/
 /art/ - all images go here, preferably in XPM format
 /bin/ - output binaries go here, lua for example
 /build/ - cmake, bakefile stuff here, and call to sub
build directories
 /docs/ - any generic docs go here
 /lib/ - output libs go here, wxlualib for example
 /samples/ - "Examples"
 /samplename/ - any multifile sample should get its own dir
 /utils/ - generic utils, bin2c for example
 /apps/ ?or programs?
 /build/ -- build for all applications
 /wxlua/ - the "Standalone" program
 /embedded/ =20
 /runtime/ - as Ray suggested, a stripped down runtime for =
wxLua
 /bindings/ - input *.i files to make the "wrappers"
 wxluawrap.lua goes in this dir so it's easy to get to for your
own projects
 /wxwidgets/ all the current .i files=20
 /bit/ - the bitwise lib for lua, maybe nothing needed here
 /other .i files for other stuff.../
 /wrappers/
 /wxwidgets/ =3D output of bindings and wxLuaPrinting, wxLuaHtmlWin
 /bit/ =3D the wrapper is the "src" of the bit library
 /output of other .i files for other stuff.../
I may have the notion of bindings and wrappers backwards though?
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
1.) Use a module approach
 /modules/
 /build/ - to have build files for all of this
 /lua/ -- lua itself
 /include/
 /src/
 /the rest of lua.../
 /wxlua/ - the wxlua library itself
 /include/ =3D internal.h, interp.h, library.h
 /src/ =3D internal.cpp, interp.cpp, library.cpp
 /wxluasocket/ - lua to cpp sockets (the current lua sockets)
 /include/ =3D debugio.h, socket.h=20
 /src/ =3D debugio.cpp, socket.cpp
 /wxluadebug/ - mechanism for getting/showing info from lua
 /include/ =3D debug.h, stacktree, splittree
 /src/ =3D debug.cpp, stacktree, splittree
 /xmlrpc/ - is is a generic lib right? so don't prepend wxlua to it?
 /include/ =3D ... Rays stuff
 /src/ =3D ... Rays stuff
 /debuggernub/ - this is a generic lib for xmlrpc? don't
prepend wxlua to it
 /include/ =3D ... Rays stuff
 /src/ =3D ... Rays stuff
 /wxluadebugger/ - this depends on wxlua so prepend wxlua to it
 /include/ =3D ... Rays stuff
 /src/ =3D ... Rays stuff
I think Klaas is suggesting that a user will set the include path to
wxLua/modules and then in a cpp file do
#include "wxlua/include/xxx.h"=20
I was confused about this.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
2.) Make it look like wxWidgets
 /lua/ - lua itself in root dir since this is what this is all about
 /include/
 /src/
 /the rest of lua.../
 /include/
 /wxlua/ =3D internal.h, interp.h, library.h
 /socket/ =3D debugio.h, socket.h=20
 /debug/ =3D debug.h, stackframe.h, splittree
 /debuggernub/ =3D ... Rays stuff
 /debuggee/ =3D ... Rays stuff
 /xmlrpc/ =3D ... Rays stuff
 /src/ =3D internal.cpp, interp.cpp, library.cpp
 /socket/ =3D debugio.cpp, socket.cpp
 /debug/ =3D debug.cpp, stackframe, splittree
 /debuggernub/ =3D ... Rays stuff
 /debugger/ =3D ... Rays stuff
 /xmlrpc/ =3D ... Rays stuff
In this case you just have "wxLua/include" in your build files and just=20
#include "wxlua/xxxdir/xxx.h" in your cpp files.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
In both cases we'll build wxlualib, wxluasocketlib, wxluadebuglib,
debuggernublib, xmlrpclib, and
I vote #1.
Regards,
 John Labenski

Hi,
I like the proposal John made.
Remove indeed:
 src/ - REMOVE THIS?
 include/wxlua/ - REMOVE THIS?
The build directory could be here:
wxLua/thirdparty/build
wxLua/modules/build
wxLua/apps/build
and/or
wxLua/build
There is no need to create build directories in each module/program.
Thirdparty can go or made shorter,
I can imagine there will be other third party stuff, but not so 
important as lua. ( e.g. xmlprc )
If there is a module directory, or all is right at the top is also not 
that important.
But if putting all programs and modules and thridparty libs at the top, 
this might be confusing to users too.
So it is actually to make things more clear to users to what is what.
Keeping source and include files and import files inside a "module" is 
i think good.
And for the include path, it can be a single one, if all #include's in 
the source code are relative to .../wxLua/module or
in the othere case .../wxLua
As you say, maybe module should be called import or bindings, and the 
lua core should go up one level.
But i don;t know if bindings is always only thata, or if it sometimes 
comes with extra C++ code or even lua scripts.
A more important point is the binding code, where will the result of 
import files be build too.
It is a sort of prebuild step followed by the build of the c++ code.
This is how i handled it in Cmake, (using the bat/lua and shell files, 
but defining it as a target to get the binding code ).
I agree that when wxLua standalone uses all settings, and some other 
only a small set, this should be possible.
I think it will be complicated without editing a setup file to tune 
this, unless we solve this runtime.
What if the total binding code is always generated, but that only 
specific sets can be registrated to an application?
If the core and binding code are inside libraries, the code is only 
linked in when used ??
I believe John already suggested this too, but i am not sure.
Why not generate the bindings in the build directory too. It is in fact 
a result of a prebuild step.
After the prebuild step, the makefile take the generated c++ binding 
code from there, and with the core generates the library.
For me the next would be fine. I think it contains all directories needed.
We only need to discuss if some need to move up or down in hierarchy.
If you think it is better to move all in module and/or apps and /or 
thirdparty up one level, that is oke with me.
 wxLua/
 art/ - all images go here, preferably in XPM format
 bin/ - output binaries go here, lua for example
 build/ - cmake, bakefile stuff here, and call to sub build directories.
 docs/ - any generic docs go here
 lib/ - output libs go here, wxlualib for example
 thirdparty/
	 build/ --build for all thridparty stuff
 lua/ - lua itself
 include/
 src/
 xmlprc/
...........
 modules/
	build/ --makefile for all modules.
 wxluacore/ -- was "Library" (BUILT AS LIB TO wxLua/lib)
 include/
 src/
 wxluasocket/ -- parts of "Library" that are for sockets make this a lib too
 include/ (BUILT AS LIB TO wxLua/lib)
 src/
 wxwidgets/
 (No include since no public headers)
 src/ wxLuaPrinting.h/cpp, wxLuaHtml.h/cpp go here (COMPILE with makefile from modules build directory)
 import/ -- was "Import" (BINDINGS GET BUILT in build directory of modules)
 bit/ - there"s a lua bitwise library which might be nice
 src/
 wxtreelistctrl/ -- (for example, I don"t personally need this...)
 import/ -- assume that the person put wxTreeListCtrl on same dir level as wxLua
..........
 apps/ ?or programs?
	 build/ -- build for all applications
 wxlua/ - the "Standalone" program
 embedded/
..........
 samples/ - "Examples"
 samplename/ - any multifile sample should get its own dir
 utils/ - generic utils, bin2c for example
Regards,
Klaas
-- 
unclassified

I would look at only putting the core components required to get a wxlua
interpreter running
in any app which are:
wxLua/src/*
wxLuaInternals.cpp, wxLuaInterpreter.cpp, and wxLuaLibrary.cpp=20
The rest should be part of the wxLua/wxlua standalone app
Or maybe
wxLua/src/*
wxLuaInternals.cpp, wxLuaInterpreter.cpp, and wxLuaLibrary.cpp=20
wxLua/src/app/*
dservice.cpp wxLuaDebuggerService.cpp -- I no longer support this so can
be removed as there is no app that will interface with protocol, it will
only confuse other users
debug.cpp wxLuaDebug.cpp
debugio.cpp wxLuaDebugIO.cpp
dserver.cpp wxLuaDebugServer.cpp=20
htmlwin.cpp wxLuaHtmlWindow.cpp
printing.cpp wxLuaPrinting.cpp
socket.cpp wxLuaSocket.cpp
splttree.cpp wxLuaSplitTree.cpp
staktree.cpp wxLuaStackTree.cpp
// Agreed
dtarget.h wxLuaDebugTarget.h moved into include/wxlua from
Standalone
dtarget.cpp wxLuaDebugTarget.cpp move into src from Standalone=20
-----Original Message-----
From: wxl...@li...
[mailto:wxl...@li...] On Behalf Of John
Labenski
Sent: Friday, 3 June 2005 06:01
To: wxl...@li...
Subject: Re: [Wxlua-users] Bakefile
On 6/2/05, f18m_217828 <f18...@ya...> wrote:
> in the next week, I'd like to contribute bakefiles for the wxLua=20
> project. If this okay, then this sunday (the next 2 days I won't be=20
> able to read emails) I'll start to work on it.
This would be great, but! We gotta get the dir structure down first.
Wait for a message saying that it's done.
See the end of this message for my proposal:
"Directory structure (was Re: wxlua.sourceforge.net is opened)"
=20
I want to hear some Yea/Nays about it before I go through the trouble of
moving things. If you'd rather have it differently please post your own
full dir structure, I'm open to anything so long as we agree. I'm
finding the little snippits hard to understand and want to see the whole
thing to understand it. I don't want to do anything until I hear people
say, "yes, I can live with that, go ahead and move things"
since it really is a pain.
> My SF id is "frm" so if you grant me write permissions I'll commit to=20
> the CVS the bakefiles.
You are part of wxArt2D? It would be ok to add you by me.
> Unfortunately, I've never used wxLua before (even if I already have=20
> bakefiles ready for lua) so I need to fully understand what such build
> system should do.
>=20
> Please, can you give me a short summary about this ?
> Which libraries should be created from which source files and where=20
> should the output go ?
> Which executables should be created ?
> Does wxLua supports unicode & shared builds ?
> Are there additional tasks which the build system should take on ?
See newdirs.txt here.=20
http://cvs.sourceforge.net/viewcvs.py/wxlua/wxLua/docs/
I will update it once we figure out the dirs and describe what goes
where and how, so don't write anything based on it right now.
Regards,
 John Labenski
-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit =
http://developer.yahoo.net/?fr=3Dfad-ysdn-ostg-q22005
_______________________________________________
Wxlua-users mailing list
Wxl...@li...
https://lists.sourceforge.net/lists/listinfo/wxlua-users

On 6/2/05, f18m_217828 <f18...@ya...> wrote:
> in the next week, I'd like to contribute bakefiles for the wxLua
> project. If this okay, then this sunday (the next 2 days I won't be able
> to read emails) I'll start to work on it.
This would be great, but! We gotta get the dir structure down first.
Wait for a message saying that it's done.
See the end of this message for my proposal:
"Directory structure (was Re: wxlua.sourceforge.net is opened)"
=20
I want to hear some Yea/Nays about it before I go through the trouble
of moving things. If you'd rather have it differently please post your
own full dir structure, I'm open to anything so long as we agree. I'm
finding the little snippits hard to understand and want to see the
whole thing to understand it. I don't want to do anything until I hear
people say, "yes, I can live with that, go ahead and move things"
since it really is a pain.
> My SF id is "frm" so if you grant me write permissions I'll commit to
> the CVS the bakefiles.
You are part of wxArt2D? It would be ok to add you by me.
> Unfortunately, I've never used wxLua before (even if I already have
> bakefiles ready for lua) so I need to fully understand what such build
> system should do.
>=20
> Please, can you give me a short summary about this ?
> Which libraries should be created from which source files and where
> should the output go ?
> Which executables should be created ?
> Does wxLua supports unicode & shared builds ?
> Are there additional tasks which the build system should take on ?
See newdirs.txt here.=20
http://cvs.sourceforge.net/viewcvs.py/wxlua/wxLua/docs/
I will update it once we figure out the dirs and describe what goes
where and how, so don't write anything based on it right now.
Regards,
 John Labenski

Hi,
 in the next week, I'd like to contribute bakefiles for the wxLua 
project. If this okay, then this sunday (the next 2 days I won't be able 
to read emails) I'll start to work on it.
My SF id is "frm" so if you grant me write permissions I'll commit to 
the CVS the bakefiles.
Unfortunately, I've never used wxLua before (even if I already have 
bakefiles ready for lua) so I need to fully understand what such build 
system should do.
Please, can you give me a short summary about this ?
Which libraries should be created from which source files and where 
should the output go ?
Which executables should be created ?
Does wxLua supports unicode & shared builds ?
Are there additional tasks which the build system should take on ?
Thanks,
Francesco Montorsi

Hey guys the list is open:
wxl...@li...
Lets continue there.
Ray Gilbert wrote:
>The directory structure should reflect the various wxLua components:
>
>Lua -- the interpreter
>wxLua/lua
>
>wxWidgets Binding	-- bindings to wxWidgets
>wxLua/binding/wx
>wxLua/binding/XXX - other bindings
> 
>
Where does the C++ code generated by the binding go?
Inside the same directory here?:
wxLua/binding/wx
wxLua/binding/XXX
or should it be generated in a fixed directory ( like where object files 
will be going )?
Once the wrapped C++ code is generated, create seperate libraries, or 
one big library?
>wxLua Core	-- core binding classes, some debug support
>wxLua/src
>
>Surprisingly you only need the following to get wxLua interpreter up and
>running, all the rest is just for the wxlua program.
>wxLuaInternals.cpp, wxLuaInterpreter.cpp, and wxLuaLibrary.cpp only
> 
>
Good idea.
>
>If you want to allow wxIDE to debug it then you would add from
>wxIDE/parts
>
>wxLua/debug/debuggernub
>wxLua/debug/xmlrpc
>And cdDebuggeeNubLua
>
>To expose a debuggee xmlrpc interface for it to connect to interpreter
>process
> 
>
Klaas
-- 
unclassified

I forgot to mention my reservations about my last message with the
proposed dir structure.
I'm not sure about the "thirdparty" dir. It breaks 8.3 chars (yes I
know it doesn't matter anymore, but still...). Also, what other
thirdparty sources besides lua will we ever have? Lua itself is pretty
important so it should probably be right up front.
I think the wrappers being in a "modules" dir along with the "core"
C++ files is a little funny.
However, I do agree with it's flexibility, but as I said there are
going to be a lot of dirs, that can be inconvenient sometimes.
Ray, wrote back at wx-users and mentioned that we'll also add 3 more
dirs so this is probably a +1 for the "modules/xxx".
John Labenski

> >1) Create libs for each of these bindings, but we might have quite a
> >few of them.
> =20
> Right, that is the idea. One can of course combine small things in one l=
ib.
We need to make it so that you can have a fine control over what
wrappers get linked to your library, see the wxLUA_USE_XXX defines in
luasetup.h, there are over 100 of them. Take the printing wrappers as
an example, an embedded program might want to exclude it, but the
wxLua program wants it. I'm going to be building both types of
programs and I want to be able to do so without any special effort.
> > Use some sort of luasetup.h (equivalent to wxWidgets/include/msw/se=
tup0.h)
> > I cannot think of any way to get the lib to be compiled using a
> >user"s luasetup.h file
> > without making people edit things by hand. I think this is unworkabl=
e.
>
> Francesco is generating by bakefile inside the makefile a art2dsetup.h =
.
> Here all option are defined. Evetually there will be a program to easily=
=20
> set the options.
> Is this what you mean??
Things that we should avoid:=20
1) Making people have to edit files that will be overwritten by a new
cvs update.
2) Making people have to edit files when they switch between compiling
wxLua and their own project, both should work at the same time.
> >2) Make the "end user" compile each cpp binding into their project by
> >hand selecting them.
> wxArt2d has wrapping, it first automatically the wxLua wraps, next art2d=
=20
> module luawraps, next the application extra wraps
> There must be a means to automate this. I did it with Cmake. But i think=
=20
> bakefile can handle it too.
> And else we might simple use Unix scripting (MSYS on windows ).
I just use .bat and BASH shell scripts, it works well.=20
=3D=3D=3D=3D=3D=3D=3D=3D
I'd like to hear what Ray and Paul think of either of these two
methods and the dir structure.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Ok, back to the dir structure (but getting a handle on the above might
make this more clear too)
My only concern with the modules dir is that there are a going to be
lot of nearly empty dirs that will make navigating it a little
cumbersome.
Do the "modules" dir get "docs, bin, build" and what not too?
Hows this?=20
wxLua/
 art/ - all images go here, preferably in XPM format
 bin/ - output binaries go here, lua for example
 build/ - cmake, bakefile stuff here
 docs/ - any generic docs go here
 include/wxlua/ - REMOVE THIS?
 lib/ - output libs go here, wxlualib for example
 thirdparty/
 lua/ - lua itself=20
 include/
 src/
 ...
 modules/
 wxluacore/ -- was "Library" (BUILT AS LIB TO wxLua/lib)
 include/
 src/
 wxluasocket/ -- parts of "Library" that are for sockets make
this a lib too
 include/ (BUILT AS LIB TO wxLua/lib)
 src/
 wxwidgets/
 (No include since no public headers)
 src/ wxLuaPrinting.h/cpp, wxLuaHtml.h/cpp go here
(HOW TO COMPILE?)
 build/ (if needed ??)
 import/ -- was "Import" (WHERE DO BINDINGS GET BUILT TO?)
 bindings/ -- (PUT BINDINGS HERE?)
 bit/ - there's a lua bitwise library which might be nice
 src/ =20
 wxtreelistctrl/ -- (for example, I don't personally need this...)
 import/ -- assume that the person put wxTreeListCtrl on
same dir level as wxLua
 apps/ ?or programs?
 wxlua/ - the "Standalone" program
 embedded/
 src/ - REMOVE THIS?
 samples/ - "Examples"
 samplename/ - any multifile sample should get its own dir
 utils/ - generic utils, bin2c for example
Regards,
 John Labenski

John Labenski wrote:
>Humm, good question. I think wxLua can provide .i wrapper files for
>any library we want since they're small enough. But, I don't think we
>should include the C(++) code for any thirdparty libraries. This puts
>the burden on us to keep maintaining them and we might get overwhelmed
>by requests for features and bugfixes.
> 
>
Right, only in rare cases one does import such libraries, certainly not 
maintain them.
WxLua soon will not be such a case anymore :-)
>What about this:
>wxLua/
> import/
> wx/ - put all .i wrappers for wxWidgets in here (include contrib)
> wxtreelistctrl/ - .i wrapper (for example) for this widget at wxCode
> ...
> bindings/
> wx/ - put all created cpp wrappers for wxWidgets here
> wxtreelistctrl/ - put cpp wrappers for wxTreeListCtrl here
>
>Now, the tricky part. 
>1) Create libs for each of these bindings, but we might have quite a
>few of them.
> 
>
Right, that is the idea. One can of course combine small things in one lib.
> Use some sort of luasetup.h (equivalent to wxWidgets/include/msw/setup0.h)
> I cannot think of any way to get the lib to be compiled using a
>user's luasetup.h file
> without making people edit things by hand. I think this is unworkable.
> 
>
Francesco is generating by bakefile inside the makefile a art2dsetup.h .
Here all option are defined. Evetually there will be a program to easily 
set the options.
Is this what you mean??
>2) Make the "end user" compile each cpp binding into their project by
>hand selecting them.
> 
>
wxArt2d has wrapping, it first automatically the wxLua wraps, next art2d 
module luawraps, next the application extra wraps
There must be a means to automate this. I did it with Cmake. But i think 
bakefile can handle it too.
And else we might simple use Unix scripting (MSYS on windows ).
>I think #2 is simplest for us and more flexible since once you start
>creating libs, the number of makefiles we'll have to write/maintain
>will get out of hand.
> 
>
Francesco started a week ago to write bakefiles for wxArt2D, and nothing 
is going out of hand ;-)
There is one makefile.vc, and it creates all the different module libs.
I think we should not comprimize because we think it is difficult, 
because i think bakefile really solves the makefile problem.
>Heh, maybe a filestructure list would help, I've looked here
>http://cvs.sourceforge.net/viewcvs.py/wxart2d/wxArt2D/modules/
>but it looks like what I wrote above?
> 
>
Yes, the top of wxArt2D is almost the same.
But it starts here.
http://cvs.sourceforge.net/viewcvs.py/wxart2d/wxArt2D
http://cvs.sourceforge.net/viewcvs.py/wxart2d/wxArt2D/thirdparty
http://cvs.sourceforge.net/viewcvs.py/wxart2d/wxArt2D/modules
http://cvs.sourceforge.net/viewcvs.py/wxart2d/wxArt2D/apps
On the top there is no core wxArt2D/src, all is inside the modules.
This is what makes it a more flexible structure
This is an extra level in the directory structure, 
So in case of wxLua the base would be:
http://cvs.sourceforge.net/viewcvs.py/wxlua/wxLua
And in there:
thirdparty/lua <= a thirparty lib which i think must be there.
modules/wxluacore <= all needed to build the core of wxlua
modules/wxluacore/src
modules/wxluacore/include
modules/wxluacore/import <= import files for the core
#The next NOT the thirdparty libs itself, but the stuff to wrap it. 
#so the import files lead to source code which will be stored in there.
# and maybe some other code to make it communicate with wxluacore??
modules/whateverlibY
modules/whateverlibY/include 
modules/whateverlibY/src 
modules/whateverlibY/import <= import files for this lib
modules/whateverlibX 
modules/whateverlibX/include 
modules/whateverlibX/src 
modules/whateverlibX/import <= import files for this lib
program/wxLua <= standalone wxLua
program/Embedded <= embedded advanged sample
samples/sample1
samples/sample2
bin
utils
docs
lib/vc_lib/wxluacore.lib
lib/vc_lib/whateverlibX.lib
lib/vc_lib/whateverlibY.lib
lib/vc_dll/wxluacore.lib
lib/vc_dll/whateverlibX.lib
lib/vc_dll/whateverlibY.lib
etc. for borland or whatever
This all puts the core stuff at the same level as contributions or other wrapped libraries.
BTW ( i created the lists, see the CC: )
Klaas