wxlua-users — wxLua list for users and developers

Re: [Wxlua-users] MSW test

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

John Labenski wrote:

>wxLua now compiles and immediately dumps when run in MSW using VC freecompiler!
>
>I'm compiling it using build/msw/nmake -f makefile.vc
>  
>
Ha, but i get the error i sent (about wxSOUND_SYNC etc. ), is there not 
a better way to make sure lua.exe is generated first.

But if i ignore it, and do the next,

>then run bindings/genwxbind.bat  (after lua.exe is made in /bin)
>  
>
and at last this:

>then rerun build/msw/nmake -f makefile.vc
>  
>
I get, for which i have no idea to solve it:

        cl /c /nologo /TP /Fomsvcd\app_wxlua_lconsole.obj /MDd /DWIN32   
/D__WXDEBUG__ /D__WXMSW__  /ID:\notebook\wxwin\wxWidgets-
2.6.2\lib\vc_lib\mswd  /ID:\notebook\wxwin\wxWidgets-2.6.2\include 
/I..\..\..\modules /W4 /Od  /Zi /Fd..\..\..\bin\wxlua.pdb /D_DE
BUG   /GR /EHsc   ..\..\wxlua\src\lconsole.cpp
lconsole.cpp
        rc /fomsvcd\app_wxlua_wxlua.res  /d WIN32  /d __WXDEBUG__ /d 
__WXMSW__ /i D:\notebook\wxwin\wxWidgets-2.6.2\lib\vc_lib\msw
d /i D:\notebook\wxwin\wxWidgets-2.6.2\include /i ..\..\..\modules /d 
_DEBUG  ..\..\wxlua\src\wxlua.rc
        link /NOLOGO /OUT:..\..\..\bin\wxlua.exe  
/LIBPATH:D:\notebook\wxwin\wxWidgets-2.6.2\lib\vc_lib /DEBUG  
/LIBPATH:..\..\..\
lib\vc_lib @C:\DOCUME~1\klaas\LOCALS~1\Temp\nma02484.
LINK : warning LNK4098: defaultlib "MSVCRT" conflicts with use of other 
libs; use /NODEFAULTLIB:library
wxlua.lib(wxlua_lib_interp.obj) : error LNK2001: unresolved external 
symbol _luaX_setfreethreadhandler
wxlua.lib(wxlua_lib_interp.obj) : error LNK2001: unresolved external 
symbol _luaX_getfreethreadhandler
wxlua.lib(wxlua_lib_interp.obj) : error LNK2001: unresolved external 
symbol _luaX_setnewthreadhandler
wxlua.lib(wxlua_lib_interp.obj) : error LNK2001: unresolved external 
symbol _luaX_getnewthreadhandler
..\..\..\bin\wxlua.exe : fatal error LNK1120: 4 unresolved externals
NMAKE : fatal error U1077: 'link' : return code '0x460'
Stop.
NMAKE : fatal error U1077: 'D:\vc6\VC98\bin\NMAKE.EXE' : return code '0x2'
Stop.

D:\notebook\wxluacvs\wxLua\build\msw>

Re: [Wxlua-users] MSW test

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

wxLua now compiles and immediately dumps when run in MSW using VC freecompi=
ler!

I'm compiling it using build/msw/nmake -f makefile.vc
then run bindings/genwxbind.bat  (after lua.exe is made in /bin)
then rerun build/msw/nmake -f makefile.vc

Here's the output using the free MS debugger.

Microsoft (R) Windows Debugger  Version 6.5.0003.7
Copyright (c) Microsoft Corporation. All rights reserved.

CommandLine: C:\wxCVS\wxLua\wxLua\bin\wxlua.exe
Symbol search path is:
C:\wxCVS\wxLua\wxLua\apps\build\msw\msvcd;C:\wxCVS\wxLua\wxLua\modules\buil=
d\msw\msvcd
Executable search path is:
ModLoad: 00400000 00ab4000   wxlua.exe
ModLoad: 77f80000 77ffc000   ntdll.dll
ModLoad: 7c570000 7c623000   C:\WINNT\system32\KERNEL32.dl
...
ModLoad: 75020000 75028000   C:\WINNT\system32\WS2HELP.DLL
ModLoad: 10200000 10287000 =20
c:\WINNT\Microsoft.NET\Framework\v1.1.4322\MSVCR71D.dll
ModLoad: 7c340000 7c396000   C:\WINNT\system32\MSVCR71.dll
(6ec.8c4): Break instruction exception - code 80000003 (first chance)
eax=3D00000000 ebx=3D00131f04 ecx=3D00000009 edx=3D00000000 esi=3D7ffdf000 =
edi=3D00131f70
eip=3D77f9193c esp=3D0012f984 ebp=3D0012fc98 iopl=3D0         nv up ei pl n=
z na pe nc
cs=3D001b  ss=3D0023  ds=3D0023  es=3D0023  fs=3D003b  gs=3D0000           =
  efl=3D00000202
*** ERROR: Symbol file could not be found.  Defaulted to export
symbols for ntdll.dll -
ntdll!DbgBreakPoint:
77f9193c cc               int     3

The callstack is empty. You do get this  warning when you compile apps/wxlu=
a

        rc /fomsvcd\app_wxlua_wxlua.res  /d WIN32  /d __WXDEBUG__ /d
__WXMSW__ /i C:\wxCVS\wxWidgets\wxWidgets\lib\vc_lib\mswd /i
C:\wxCVS\wxWidgets\wxWidgets\include /i ..\..\..\modules /d _DEBUG=20
..\..\wxlua\src\wxlua.rc
        link /NOLOGO /OUT:..\..\..\bin\wxlua.exe=20
/LIBPATH:C:\wxCVS\wxWidgets\wxWidgets\lib\vc_lib /DEBUG=20
/LIBPATH:..\..\..\lib\vc_lib
@c:\DOCUME~1\JLABEN~1\LOCALS~1\Temp\nm222.tmp
LINK : warning LNK4098: defaultlib 'MSVCRT' conflicts with use of
other libs; use /NODEFAULTLIB:library
        cd c:\wxCVS\wxLua\wxLua\build\msw

I also can't seem to get the debugger to do simple things like put a
breakpoint in wxApp::OnInit.

It complains about
"The source line has multiple addresses, select desired address"
wxlua.cpp
wxlua!wxLuaStandAloneApp::OnInit
wxlua!wxLuaObject_GetObject         <--- ! this is in wxbind?

Somehow the linking is all messed up, any ideas?

Regards,
    John Labenski

Re: luasetup.h and wxLua build system (was Re: [Wxlua-users] wxLua Compiles and works in Linux)

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

John Labenski wrote:

>* The bottom line: It sounds like the /I include "trick" is our best
>best that'll work for the most number of compilers.
>
With  WXLUASETUP_DIR and WXBIND_TARGET_LIBDIR as options to the makefiles.
So its the include trick + output redirection.
I think :-)

> If there are no
>objections, lets do it this way and move on to the next hurdle, how to
>use your own .i files with wxLua.
>  
>
Good idea! I first will read your other repsond on that once again, it 
is not that easy ;-)

Klaas

Re: [Wxlua-users] MSW test

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

On 11/22/05, Francesco Montorsi <f18...@ya...> wrote:
> > These are fixed as of yesterday. The bakefiles are also fixed, but I
> > wasn't able to run bakefile_gen again.
> which problems did you have with bakefile_gen ?

The one with %WXWIN% in linux, maybe you could rerun it? If not I'll
try again later tonight if possible.

Regards,
    John Labenski

Re: luasetup.h and wxLua build system (was Re: [Wxlua-users] wxLua Compiles and works in Linux)

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

> > In principle the copy is already made, to your own project. It has
> > nothing to do with SHARED, UNICODE etc.
> > Still for one luasetup.h all those type of builds ( synchromized with
> > the wxWidgets in WXWIN) should be generated. They do not variate with
> > lausetup.h, but only because of build type.
> ok, that is: we want separate build folders for different build settings =
and not only
> (through the WXLUASETUP_DIR and WXBIND_TARGET_LIBDIR options) for differe=
nt luasetup.h.
> Anyway this is already in place; i.e. object files are sent to the
> build\msw\[compiler][u][d] folder and library files into lib\[compiler]_[=
dll|lib]).
> So, no problem ;)

Precisely.

> >>> HOWEVER! This cannot be made to work for MSVS dsp files, can it?
> >>
> >> right; unfortunately IDEs do not allow you to specify options which
> >> are in "string" form. That is, you can make multiple configurations in
> >> a DSP file for an option which has a finite set of possible values
> >> (like BUILD=3Ddebug/release) but you can't do that for a "path" option=
.
> >
> > Hmmm, i really see /I$(WXWIN)\lib\.
> > Is that not enough to do the trick ?
> I forgot about environment variables.
> But you're right; they could solve the problem: we ask the user to set a =
WXLUASETUP_DIR
> and WXBIND_TARGET_LIBDIR env variables and then use these in the DSP.
> However this means that just downloading wxLua and open the DSW file won'=
t work: the user
> will also need to set the env variables first as this way do not allow to=
 specify a
> "default-value-in-case-the-env-var-is-missing"...
>
> So I don't know if it's better to limit project files to the default luas=
etup.h or to
> force them to look for the WXLUASETUP_DIR and WXBIND_TARGET_LIBDIR env va=
rs...

Nah, this won't work too well. Let's say there's a bug in wxLua, maybe
the .i files are messed up and some function doesn't work. You fix
them and regenerate with genwxbind that outputs into modules/wxbind.
Now you need to recompile wxbind and relink your program, BUT! you
should also test apps/wxlua to see if you didn't break that by
accident. So, you need to compile the default wxbind lib and relink
apps/wxlua. Using environment variables means that you open VS to do
your app, close it, reset env vars and open it again to do apps/wxlua,
close it, reset env vars, go back to your app.

I think Francesco had it right, if you use dsp files you get the
default wxbind lib, if you really want your own wxbind lib you copy
the dsp file that builds wxbind and edit it yourself, tough luck on
them. :(  It's actually not too much work for them really. In fact
they can just put their own copy of the bakefile used to build wxbind
right into their project tree, modify it as necessary to point back to
wxLua, and generate their own project files to use.

* The bottom line: It sounds like the /I include "trick" is our best
best that'll work for the most number of compilers. If there are no
objections, lets do it this way and move on to the next hurdle, how to
use your own .i files with wxLua.

Thanks,
    John Labenski

Re: [Wxlua-users] MSW test

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

Hi,

John Labenski wrote:
> These are fixed as of yesterday. The bakefiles are also fixed, but I
> wasn't able to run bakefile_gen again.
which problems did you have with bakefile_gen ?

Francesco

Re: luasetup.h and wxLua build system (was Re: [Wxlua-users] wxLua Compiles and works in Linux)

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

On 11/22/05, klaas.holwerda <kho...@xs...> wrote:
> So wxArt2D has its own module with *.i files, leading to an extra
> library  with wxLua art2d  bindings.  To conclude, this  is part of its
> own project files. No need for a dedicated project file from wxLua itself=
.
> If however one only wants to link in a partly wxLua ( which can be the
> case for certain wxArt2D applications, where lua is used only for a
> command interpreter, and nothing fancy ), we get to the situation that
> John explained.
> And again here i think it should be the job of the wxart2d\project/make
> files to generate this partly wxLua by taking only parts of *.i , having
> a customized luasetup.h in wxArt2D.

The beauty of the new genwxbind.lua program (over wxluawrap.lua) is
that it generates .cpp files that contain all the appropriate #if
statements to run in any platform and build. This means that you only
run genwxbind whenever you edit the .i files. wxLua itself will
distribute a full set of wrapped files for wxWidgets in
modules/wxbind, I just haven't committed them yet until we get the
build system figured out.

I will add some docs about this. As I adapt my project and wxLua to
work easily with external projects I'll write the docs.

> In short i think we need a system for external wxLua project ( app or
> lib ), in which on can take the complete wxLua or a partly binding and
> at the same time extend it with extra bindings, and that alltogether
> could best go into a library which belongs to that external project itsel=
f.
> I would non be suprized that in some far future there will be a
> lua_art2dsetup.h next to the luasetup.h, making it able to choose
> between  the various wxArt2d modules wrapped into lua.

wxArt2d should have it's own set of .i files (for wxArt2D) and the
result of running genwxbind.lua (the generated .cpp wrapper files) in
wxArt2d's cvs.

This is what it looks like

make wxLua (modules/wxlua modules/wxluadebug whatever else)
-> have lib_wxlua lib_wxluadebug to link to in wxLua's build tree

from wxArt2d compile you OWN lib_wxbind (from modules/wxbind) that
contains the appropriate classes as set by luasetup.h (or just use the
default, eg. you may not want to wrap wxStyledTextCtrl or wxGrid if
you don't use it)
-> have wx_wxluabind in wxArt2D's build tree somewhere

compile wxArt2D's equivalent to modules/wxbind, pregenerated from your
.i files by the same genwxbind.lua that wxLua uses itself, using your
own settings similar to bindings/wxwidgets/wx.rules
-> have lib_wxluaart2d in wxArt2D's build tree somewhere

build the rest of wxArt2d
-> lib_wxart2d...

build your app and link to
   lib_wxlua, lib_wxluadebug, lib_wxluabind (your own version),
lib_wxluabindart2d, whatever else.

When you create a new lua_State you need to add the bindings in
lib_wxluabindart2d (the ones in lib_wxluabind are automatically
added). All of wxArt2d is accessible to wxLua in the lua "namespace"
of wxart2d (or whatever you want to call it). This part needs some
work and is completely untested by me, but there should be no
implementation problems with it.

> So i wonder if a VC project file is really helping in such a situation.
> But of course it will be good to help a user on his way, since wxLua/lua
> is often really meant to be used with/inside other applications to
> extend them with scripting.  We must make something which makes this
> easy to do.
> Maybe we must generate some sort of template makefile/project files, or
> even better bakefile template itself, within wxLua, which makes this
> easy to include in our own projects?

This is another solution, but I think that the existing
bakefiles/buildfiles are good enough for templates. My worry about
luasetup.h is that I want to be able to use the wxLua build files from
external projects. This should work for most people, the people who
have really special needs will be on their own.

> John would you be able to explain how you picture the use of
> genwxbind.bat in an external project ?  e.g. should one extend wx.rules?
> In that case, one will need a copy of that file in its own projects i
> think, but will it still work from  there? Did you already use wxLua
> like it is now in one of your own project (which has its own bindings ).
> How do you do that?

I have not used the new version yet, see above about wx.rules. Basicly
wx.rules (the name is not important, see genwxbind.bat) sets all the
output dirs and everything so that genwxbind can be run from anywhere
and output to anywhere.

I will try to test some things out later this week, but *FIRST* I
really want to get the luasetup.h stuff figured out once and for all.
I have some previous messages to read through so maybe it's already
settled? :)

-John

Re: [Wxlua-users] MSW test

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

On 11/22/05, klaas.holwerda <kho...@xs...> wrote:
> Hi,
>
> On MSW, this is where it stops. maybe some setting not detected?
>
>         cl /c /nologo /TP /Fomsvcd\wxbind_lib_wx_define.obj /MDd
> /DWIN32   /D__WXDEBUG__ /D__WXMSW__  /ID:\notebook\wxwin\wxWidget
> s-2.6.2\lib\vc_lib\mswd  /ID:\notebook\wxwin\wxWidgets-2.6.2\include
> /I..\..\..\modules /W4 /Od  /Zi /Fd..\..\..\lib\vc_lib\wxbind
> .pdb /D_DEBUG   /ID:\notebook\wxwin\wxWidgets-2.6.2\contrib\include /GR
> /EHsc    ..\..\wxbind\src\wx_define.cpp
> wx_define.cpp
> ..\..\wxbind\src\wx_define.cpp(708) : error C2065: 'wxSOUND_ASYNC' :
> undeclared identifier
> ..\..\wxbind\src\wx_define.cpp(709) : error C2065: 'wxSOUND_LOOP' :
> undeclared identifier
> ..\..\wxbind\src\wx_define.cpp(710) : error C2065: 'wxSOUND_SYNC' :
> undeclared identifier
> NMAKE : fatal error U1077: 'cl' : return code '0x2'
> Stop.
> NMAKE : fatal error U1077: 'D:\vc6\VC98\bin\NMAKE.EXE' : return code '0x2=
'
> Stop.

These are fixed as of yesterday. The bakefiles are also fixed, but I
wasn't able to run bakefile_gen again.

Regards,
    John Labenski

[Wxlua-users] MSW test

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

Hi,

On MSW, this is where it stops. maybe some setting not detected?

        cl /c /nologo /TP /Fomsvcd\wxbind_lib_wx_define.obj /MDd 
/DWIN32   /D__WXDEBUG__ /D__WXMSW__  /ID:\notebook\wxwin\wxWidget
s-2.6.2\lib\vc_lib\mswd  /ID:\notebook\wxwin\wxWidgets-2.6.2\include 
/I..\..\..\modules /W4 /Od  /Zi /Fd..\..\..\lib\vc_lib\wxbind
.pdb /D_DEBUG   /ID:\notebook\wxwin\wxWidgets-2.6.2\contrib\include /GR 
/EHsc    ..\..\wxbind\src\wx_define.cpp
wx_define.cpp
..\..\wxbind\src\wx_define.cpp(708) : error C2065: 'wxSOUND_ASYNC' : 
undeclared identifier
..\..\wxbind\src\wx_define.cpp(709) : error C2065: 'wxSOUND_LOOP' : 
undeclared identifier
..\..\wxbind\src\wx_define.cpp(710) : error C2065: 'wxSOUND_SYNC' : 
undeclared identifier
NMAKE : fatal error U1077: 'cl' : return code '0x2'
Stop.
NMAKE : fatal error U1077: 'D:\vc6\VC98\bin\NMAKE.EXE' : return code '0x2'
Stop.

D:\notebook\wxluacvs\wxLua\build\msw>


Klaas

Re: luasetup.h and wxLua build system (was Re: [Wxlua-users] wxLua Compiles and works in Linux)

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

Francesco Montorsi wrote:

>
>
> So I don't know if it's better to limit project files to the default 
> luasetup.h or to force them to look for the WXLUASETUP_DIR and 
> WXBIND_TARGET_LIBDIR env vars...

The user already needs to set WXWIN, so one more or less will not hurt.
But there is i think more to it.
One job to do is to generate the custom made wxLua version for an 
external project. But that same project will have its own make files or 
project files.
In wxArt2D for example we will not limit the wxLua, only extend it with 
extra bindings. So i assume we will use something like a wxlua-config to 
get the information about where wxLua is etc. and on windows the envvar 
WXLUA will be used to find it.
So wxArt2D has its own module with *.i files, leading to an extra 
library  with wxLua art2d  bindings.  To conclude, this  is part of its 
own project files. No need for a dedicated project file from wxLua itself.
If however one only wants to link in a partly wxLua ( which can be the 
case for certain wxArt2D applications, where lua is used only for a 
command interpreter, and nothing fancy ), we get to the situation that 
John explained.
And again here i think it should be the job of the wxart2d\project/make 
files to generate this partly wxLua by taking only parts of *.i , having 
a customized luasetup.h in wxArt2D.

In short i think we need a system for external wxLua project ( app or 
lib ), in which on can take the complete wxLua or a partly binding and 
at the same time extend it with extra bindings, and that alltogether 
could best go into a library which belongs to that external project itself.
I would non be suprized that in some far future there will be a 
lua_art2dsetup.h next to the luasetup.h, making it able to choose 
between  the various wxArt2d modules wrapped into lua.

So i wonder if a VC project file is really helping in such a situation.
But of course it will be good to help a user on his way, since wxLua/lua 
is often really meant to be used with/inside other applications to 
extend them with scripting.  We must make something which makes this 
easy to do.
Maybe we must generate some sort of template makefile/project files, or 
even better bakefile template itself, within wxLua, which makes this 
easy to include in our own projects?
 
John would you be able to explain how you picture the use of  
genwxbind.bat in an external project ?  e.g. should one extend wx.rules?
In that case, one will need a copy of that file in its own projects i 
think, but will it still work from  there? Did you already use wxLua 
like it is now in one of your own project (which has its own bindings ). 
How do you do that?

Trying to prepare myself for having the new wxLua used in wxArt2D ;-)

Thanks all,

Klaas







 

Re: luasetup.h and wxLua build system (was Re: [Wxlua-users] wxLua Compiles and works in Linux)

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

Hi,

klaas.holwerda wrote:
> Francesco Montorsi wrote:
>> So, reformulating the problem: wxLua doesn't care about build 
>> settings. The user must be able to build wxLua(bind) using exactly the 
>> same build settings (SHARED,BUILD,UNICODE, I mean) but with different 
>> luasetup.h files.
>> So, copying luasetup.h as wxWidgets does, won't absolutely work, right ?
> 
> 
> In principle the copy is already made, to your own project. It has 
> nothing to do with SHARED, UNICODE etc.
> Still for one luasetup.h all those type of builds ( synchromized with 
> the wxWidgets in WXWIN) should be generated. They do not variate with 
> lausetup.h, but only because of build type.
ok, that is: we want separate build folders for different build settings and not only 
(through the WXLUASETUP_DIR and WXBIND_TARGET_LIBDIR options) for different luasetup.h.
Anyway this is already in place; i.e. object files are sent to the 
build\msw\[compiler][u][d] folder and library files into lib\[compiler]_[dll|lib]).
So, no problem ;)


>>> 4) In the makefile for wxluabind we have
>>> WXBIND_TARGET_LIBDIR = $(WXPREFIX)/lib (or whereever)
>>> so that again, in your own project files you can do
>>> WXBIND_TARGET_LIBDIR = /some/path/to/somewhere/else
>>>
>>> Now you can have two different libs for two different luasetup.h at
>>> the same time.
>>
>>
>>
>>    nmake -fmakefile.vc WXLUASETUP_DIR=c:\myproject\include 
>> WXBIND_TARGET_LIBDIR=c:\myproject\lib
as you said, we also need to send object files there, not only the generated library 
otherwise the object files for the user-luasetup.h could conflict with other builds of wxLua.



>>> HOWEVER! This cannot be made to work for MSVS dsp files, can it?
>>
>>
>> right; unfortunately IDEs do not allow you to specify options which 
>> are in "string" form. That is, you can make multiple configurations in 
>> a DSP file for an option which has a finite set of possible values 
>> (like BUILD=debug/release) but you can't do that for a "path" option.
> 
> 
> Hmmm, i really see /I$(WXWIN)\lib\.
> Is that not enough to do the trick ?
I forgot about environment variables.
But you're right; they could solve the problem: we ask the user to set a WXLUASETUP_DIR 
and WXBIND_TARGET_LIBDIR env variables and then use these in the DSP.
However this means that just downloading wxLua and open the DSW file won't work: the user 
will also need to set the env variables first as this way do not allow to specify a 
"default-value-in-case-the-env-var-is-missing"...

So I don't know if it's better to limit project files to the default luasetup.h or to 
force them to look for the WXLUASETUP_DIR and WXBIND_TARGET_LIBDIR env vars...

Francesco

Re: luasetup.h and wxLua build system (was Re: [Wxlua-users] wxLua Compiles and works in Linux)

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

Francesco Montorsi wrote:

>
> So, reformulating the problem: wxLua doesn't care about build 
> settings. The user must be able to build wxLua(bind) using exactly the 
> same build settings (SHARED,BUILD,UNICODE, I mean) but with different 
> luasetup.h files.
> So, copying luasetup.h as wxWidgets does, won't absolutely work, right ?

In principle the copy is already made, to your own project. It has 
nothing to do with SHARED, UNICODE etc.
Still for one luasetup.h all those type of builds ( synchromized with 
the wxWidgets in WXWIN) should be generated. They do not variate with 
lausetup.h, but only because of build type.

>
>
> I agree; this is a Good Solution for me and it's 100% compatible with 
> bakefile.
> I would make WXLUASETUP_DIR an option for makefiles with a default 
> value of "./", so that to build with default luasetup.h you do:
>
>    nmake -fmakefile.vc
>
> but to build with your custom luasetup.h:
>
>    nmake -fmakefile.vc WXLUASETUP_DIR=c:\myproject\include

nice.

>
>
>> 4) In the makefile for wxluabind we have
>> WXBIND_TARGET_LIBDIR = $(WXPREFIX)/lib (or whereever)
>> so that again, in your own project files you can do
>> WXBIND_TARGET_LIBDIR = /some/path/to/somewhere/else
>>
>> Now you can have two different libs for two different luasetup.h at
>> the same time.
>
>
>    nmake -fmakefile.vc WXLUASETUP_DIR=c:\myproject\include 
> WXBIND_TARGET_LIBDIR=c:\myproject\lib

cool!

>
>
>> HOWEVER! This cannot be made to work for MSVS dsp files, can it?
>
> right; unfortunately IDEs do not allow you to specify options which 
> are in "string" form. That is, you can make multiple configurations in 
> a DSP file for an option which has a finite set of possible values 
> (like BUILD=debug/release) but you can't do that for a "path" option.

Hmmm, i really see /I$(WXWIN)\lib\.
Is that not enough to do the trick ?

Maybe i do not understand the problem in the dsp files,

Klaas

Re: [Wxlua-users] wxLua Compiles and works in Linux

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

Hi John,

John Labenski wrote:

>I hope this makes it a little more clear why I want this to work seamlessly.
>  
>
Maybe you should add this somewhere in the docs dir, as HTML file.
I think the process of generating wxLua should be documented a little,
so we all know what going on. This would be  a start.

>****************************
>
>In terms of copying the luasetup.h that was used to generate each
>library, it's probably not necessary since it's part of your project
>and you can get at it yourself.
>  
>
I understand you have it in your/my project. And  very likely for 
wxArt2D this would result in  a  seperate library.
So leafs the directories to output object and library files etc.  of the 
specific (on purpose limited) bindings. 

>**********************************
>The solution: (or the only way I see it working)
>
>1) In modules/wxbind/include/wxbind.h we have #include "luasetup.h"
>with *no* path before it.
>  
>
oke

>2) We put a complete version of luasetup.h in
>modules/wxbind/src/luasetup.h so it'll be included using the default
>search path of ./ that all compilers support.
>
>  
>
Hope so.

>3) In the makefile for wxluabind we have
>WXLUASETUP_DIR = ./
>  
>
Oke, that should work :-)

>4) In the makefile for wxluabind we have
>WXBIND_TARGET_LIBDIR = $(WXPREFIX)/lib (or whereever)
>so that again, in your own project files you can do
>WXBIND_TARGET_LIBDIR = /some/path/to/somewhere/else
>
>Now you can have two different libs for two different luasetup.h at
>the same time.
>  
>
Right, i think we need the object files to be generated there too.

>HOWEVER! This cannot be made to work for MSVS dsp files, can it?
>  
>
Argh.
But i think it can, the dsp files can use variables, i seen them ( like 
WXWIN).

>>;)
>>    
>>
>
>As you probably saw, I ased on wx-users, but I don't think it's really possible.
>  
>
I am not sure. If IDE (some) do understand $WXWIN, i think there is a 
good change. The wxArt2D project files generated by bakefile do have them.

Klaas

luasetup.h and wxLua build system (was Re: [Wxlua-users] wxLua Compiles and works in Linux)

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

Hi,

Thanks John for the good explanation; now everything is crystal clear ;)


 >>So for the user it's "easy" to customize his wx builds: he creates its setup.h (probably
 >>modifying the default one) in the right folder and then gives the makefile command.
 >>This system works even for IDEs...
 >
 > The thing is, luasetup.h doesn't care what platform or build you're
 > using. The bindings themselves have all the wxUSE_XXX that are defined
 > in wxWidget's setup.h.
So, reformulating the problem: wxLua doesn't care about build settings. The user must be 
able to build wxLua(bind) using exactly the same build settings (SHARED,BUILD,UNICODE, I 
mean) but with different luasetup.h files.
So, copying luasetup.h as wxWidgets does, won't absolutely work, right ?


> **********************************
> The solution: (or the only way I see it working)
> 
> 1) In modules/wxbind/include/wxbind.h we have #include "luasetup.h"
> with *no* path before it.
> 
> 2) We put a complete version of luasetup.h in
> modules/wxbind/src/luasetup.h so it'll be included using the default
> search path of ./ that all compilers support.
> 
> 3) In the makefile for wxluabind we have
> WXLUASETUP_DIR = ./
> .cpp.o:
>         $(CXX) -I $(WXLUASETUP_DIR) -c $(CXXFLAGS) $(APPEXTRADEFS)-o $@ $<
> 
> so that by default it uses the luasetup.h in modules/wxbind/src and
> when you call the makefile from your project's makefiles you define
> WXLUASETUP_DIR = "path/to/my/project/where/my/luasetup/is"
> so it'll find your own luasetup.h first.
I agree; this is a Good Solution for me and it's 100% compatible with bakefile.
I would make WXLUASETUP_DIR an option for makefiles with a default value of "./", so that 
to build with default luasetup.h you do:

    nmake -fmakefile.vc

but to build with your custom luasetup.h:

    nmake -fmakefile.vc WXLUASETUP_DIR=c:\myproject\include


> 4) In the makefile for wxluabind we have
> WXBIND_TARGET_LIBDIR = $(WXPREFIX)/lib (or whereever)
> so that again, in your own project files you can do
> WXBIND_TARGET_LIBDIR = /some/path/to/somewhere/else
> 
> Now you can have two different libs for two different luasetup.h at
> the same time.
ok sure; also output path needs to be user-customizable.
Again I would make WXBIND_TARGET_LIBDIR an option so that, expanding the previuos example:

for default luasetup.h:

    nmake -fmakefile.vc

but to build with your custom luasetup.h:

    nmake -fmakefile.vc WXLUASETUP_DIR=c:\myproject\include 
WXBIND_TARGET_LIBDIR=c:\myproject\lib


> HOWEVER! This cannot be made to work for MSVS dsp files, can it?
right; unfortunately IDEs do not allow you to specify options which are in "string" form. 
That is, you can make multiple configurations in a DSP file for an option which has a 
finite set of possible values (like BUILD=debug/release) but you can't do that for a 
"path" option.

I think that we should make IDE project files fixed to work with default luasetup.h, and 
allow the user to build wxLua(bind) using his own luasetup.h only from command-line makefiles.
After all, IMO this is not a big problem, specially if you want a custom wxLua(bind) for 
your project (which means that you're not a newbie).

Let me know if I can proceed with solution above,
Francesco

Re: [Wxlua-users] wxLua Compiles and works in Linux

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

Ok, here's the scenario.

$cvs co wxLua  # get clean wxLua tree
$cd wxLua/build/msw && nmake -f makefile.vc # build everything

So far so good, you don't have to do anything other than build it to
get a completely working wxLua (the IDE app). [If we want we can have
the luasetup.h for the IDE as luasetup0.h, but I can't think of why
you wouldn't want the full bindings for it.]

* Now - here's my issue. You have your own project (in it's own tree)
that uses wxLua as a library. You may want a smaller version of the
bindings, so you'll need your own luasetup.h in your own project's
files that you maintain where you've turned off some things that will
never be used.

$cd myproject/build && nmake -f makefile.vc

****************************
Now for the wxLua developers, we'll work on wxLua and then have to
rebuild both the wxLua IDE and our projects to test things. This means
that there will be two different lib_wxluabind. I do *not* want to
have to copy/edit luasetup.h or do anything other then just type make
for each. I also need to be able to run them both at the same time for
testing.

I hope this makes it a little more clear why I want this to work seamlessly=
.

****************************

In terms of copying the luasetup.h that was used to generate each
library, it's probably not necessary since it's part of your project
and you can get at it yourself.

**********************************
The solution: (or the only way I see it working)

1) In modules/wxbind/include/wxbind.h we have #include "luasetup.h"
with *no* path before it.

2) We put a complete version of luasetup.h in
modules/wxbind/src/luasetup.h so it'll be included using the default
search path of ./ that all compilers support.

3) In the makefile for wxluabind we have
WXLUASETUP_DIR =3D ./
.cpp.o:
        $(CXX) -I $(WXLUASETUP_DIR) -c $(CXXFLAGS) $(APPEXTRADEFS)-o $@ $<

so that by default it uses the luasetup.h in modules/wxbind/src and
when you call the makefile from your project's makefiles you define
WXLUASETUP_DIR =3D "path/to/my/project/where/my/luasetup/is"
so it'll find your own luasetup.h first.

4) In the makefile for wxluabind we have
WXBIND_TARGET_LIBDIR =3D $(WXPREFIX)/lib (or whereever)
so that again, in your own project files you can do
WXBIND_TARGET_LIBDIR =3D /some/path/to/somewhere/else

Now you can have two different libs for two different luasetup.h at
the same time.

HOWEVER! This cannot be made to work for MSVS dsp files, can it?

**********************************

On 11/21/05, Francesco Montorsi <f18...@ya...> wrote:
> Sorry but I'm missing the point of this discussion; maybe because it's la=
te here ;)
> I don't understand if the problem is:
>
> 1) be able to build wxLua against different wxWidgets configurations
>     (which can be solved using as output dir lib/$(COMPILER)_[dll|lib])
> 2) be able to build wxLua with different luasetup.h files
>     (which I would solve, on win32, using the same approach taken by wxWi=
dgets, see below).
>
> I guess the problem is mainly #2... in this case:

Yes #2, luasetup.h has little if nothing to do with wxWidget's setup.h.

> >> The biggest problem, I think, is how to use two luasetup.h files
> >> without having to copy the new one into place between builds.
> >>
> > Right, i see. Maybe the wxWidgets way of copying the setup.h to some th=
e
> > lib dir first before starting to compile. That is: it only copies it if
> > not already there.
> as Klaas said, wxWidgets keeps a different setup.h for each different com=
binations of
> SHARED/BUILD/UNICODE options. If the corrispondent setup.h (located in
> $(WXWIN)/lib/$(COMPILER)_[lib|dll]/msw[ud]/wx/setup.h IIRC) does not exis=
t, then a default
> one is copied there.
>
> So for the user it's "easy" to customize his wx builds: he creates its se=
tup.h (probably
> modifying the default one) in the right folder and then gives the makefil=
e command.
> This system works even for IDEs...

The thing is, luasetup.h doesn't care what platform or build you're
using. The bindings themselves have all the wxUSE_XXX that are defined
in wxWidget's setup.h.

> > The problem is the to have the makefile use setable output directories
> > for libraries and object files, so one can have several builds.
> > I wonder how wxWidgets developers  test  different  setup.h  combinatio=
n.
> I don't know this... but I'd like to ;)

As you probably saw, I ased on wx-users, but I don't think it's really poss=
ible.

-John

Re: [Wxlua-users] wxLua Compiles and works in Linux

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

Hi,

Sorry but I'm missing the point of this discussion; maybe because it's late here ;)
I don't understand if the problem is:

1) be able to build wxLua against different wxWidgets configurations
    (which can be solved using as output dir lib/$(COMPILER)_[dll|lib])

2) be able to build wxLua with different luasetup.h files
    (which I would solve, on win32, using the same approach taken by wxWidgets, see below).

3) both

I guess the problem is mainly #2... in this case:


>> The biggest problem, I think, is how to use two luasetup.h files
>> without having to copy the new one into place between builds.
>>  
> Right, i see. Maybe the wxWidgets way of copying the setup.h to some the 
> lib dir first before starting to compile. That is: it only copies it if 
> not already there.
as Klaas said, wxWidgets keeps a different setup.h for each different combinations of
SHARED/BUILD/UNICODE options. If the corrispondent setup.h (located in 
$(WXWIN)/lib/$(COMPILER)_[lib|dll]/msw[ud]/wx/setup.h IIRC) does not exist, then a default 
one is copied there.

So for the user it's "easy" to customize his wx builds: he creates its setup.h (probably 
modifying the default one) in the right folder and then gives the makefile command.
This system works even for IDEs...


> This in combination with a build/lib directory to be set by the user, 
> will do the job, not? 
well, the user-customizable BUILD folder is not required - but having implemented that for 
wxArt2d, I think I could add it to wxLua, too ;)

>If the 
> $WXLUA_BUILD/lib/vc_lib/mswXXX/wxLua/luasetup.h is found first, at least 
> one can have more then one.
right

> The problem is the to have the makefile use setable output directories 
> for libraries and object files, so one can have several builds.
> I wonder how wxWidgets developers  test  different  setup.h  combination.
I don't know this... but I'd like to ;)

Francesco

Re: [Wxlua-users] wxLua Compiles and works in Linux

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

John Labenski wrote:

>  
>
>The biggest problem, I think, is how to use two luasetup.h files
>without having to copy the new one into place between builds.
>  
>
Right, i see. Maybe the wxWidgets way of copying the setup.h to some the 
lib dir first before starting to compile. That is: it only copies it if 
not already there.
This in combination with a build/lib directory to be set by the user, 
will do the job, not? If the 
$WXLUA_BUILD/lib/vc_lib/mswXXX/wxLua/luasetup.h is found first, at least 
one can have more then one.
The problem is the to have the makefile use setable output directories 
for libraries and object files, so one can have several builds.
I wonder how wxWidgets developers  test  different  setup.h  combination.

Regards,

Klaas
 

Re: [Wxlua-users] wxLua Compiles and works in Linux

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

> I am a bit confused by having setup.h of wxWidgest and the one fro
> luasetup.h.
> I think that luasetup.h should at least take into a ccount what is
> already done in setup.h.
> e.g. No FL, then luasetup.h should not see it. It makes no sence
> otherewise, since it will not compile.
> What is the current way this is decided?

The wxWidgets setup.h *is* used in the bindings. luasetup.h is just a
way to trim down the size of the bindings library.

> >>why would user need to override the output library name ?
> >>Also, the output path should be the usual wxLua/lib...
> >
> >To have two different compiled versions of lib_wxluabind, see above.
> >
> I think to build directories will have the same effect, and might be a
> better solution.
> Like in Cmake one chooses the build directory. But since in bakefile the
> build dir is already defined,
> a copy should do. ( understand it is small enough, and lib dirs etc. are
> all defined in there. ).

The biggest problem, I think, is how to use two luasetup.h files
without having to copy the new one into place between builds.

Regards,
    John Labenski

Re: [Wxlua-users] wxLua Compiles and works in Linux

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

Hi,

I hope to switch soon, but try on MSW had some problems ( wil report 
them this evening ).
Happy to see some movement :-)

John Labenski wrote:

>
>The way I see it is that you need to get all the things in luasetup.h
>defined independently for each instance of the library and you need to
>either give the library a different name or destination dir.
>  
>
I thought Franscesco made something for that.
At least Cmake does this always, and i asked for something simular for 
bakefile.
So one could have several build directories next to eachother.
I agree that building to/in several build directories and/or destination 
directories is a must.

I am a bit confused by having setup.h of wxWidgest and the one fro 
luasetup.h.
I think that luasetup.h should at least take into a ccount what is 
already done in setup.h.
e.g. No FL, then luasetup.h should not see it. It makes no sence 
otherewise, since it will not compile.
What is the current way this is decided?

>  
>
>>>      
>>>
>>why would user need to override the output library name ?
>>Also, the output path should be the usual wxLua/lib...
>>    
>>
>
>To have two different compiled versions of lib_wxluabind, see above.
>  
>
I think to build directories will have the same effect, and might be a 
better solution.
Like in Cmake one chooses the build directory. But since in bakefile the 
build dir is already defined,
a copy should do. ( understand it is small enough, and lib dirs etc. are 
all defined in there. ).

Or do you also want to install ( /user/local/lib ) different version??

Thanks John and Francesco!

Klaas






-- 
Unclassified

Re: [Wxlua-users] wxLua Compiles and works in Linux

[Crow <xo...@bl...>]

John Labenski <jla...@gm...> wrote:
(21/11/2005 00:16)

>DOS only lets you have command lines < 256 chars IIRC. This can be
>used up pretty quickly, but would work though.
>


If you needed more, batch files will allow it. I just did a quick check in a DOS box in W98, and it seems to be unlimited, or at least very long. The limit at the command line itself is 127 bytes.


Good to see things moving here. I'm observing it, but I don't understand it all. But when the new release is ready, I'll try DX7-Edit on it and look at what happens, especially any differences that I ought to watch for.

Re: [Wxlua-users] wxLua Compiles and works in Linux

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

On 11/20/05, Francesco Montorsi <f18...@ya...> wrote:
> > I think the solution to making it possible to have multiple version of
> > the wxlua bindings for different projects lies in making the compiler
> > include luasetup.h for us.
>
> This is not a "standard" solution; rather that, I'd prefer to use the sam=
e system adopted
> for wxWidgets: on win32 they provide a default setup.h which can then be =
customized by the
> user before compiling.

How can you have multiple configurations of wxWidgets using nmake? I
don't think it's possible since if you edit setup.h it just completely
recompiles everything. You can change the output directory however,
see CFG=3D in build/msw/config.vc. If you're working on two configs at
the same time it seems like you have to copy/edit setup.h and then
completely recompile. See below for why I think wxLua is a little
different and that having two independent configurations of wxLuaBind
is normal for a C++ developer.

> On unix a setup.h is generated from setup.h.in using the values of the --=
enable-xxx features.

On linux with configure it can work, in fact I do have two independent
versions of wxWidgets right now.


I need to have (at least) two different wxLuaBind libraries and I
think this scenario would be similar for anyone using wxLua in a C++
program. One for apps/wxlua with basically everything turned on and
the second for my programs that embed wxLua with some stuff turned
off. I'm trying to think of how we can make use of the build files in
wxLua for external projects rather than writing and maintaining our
own. We need to make it so that you can build both at the same time
without needing to copy the appropriate luasetup.h and also as a
developer using CVS I don't want my luasetup.h getting constantly
overwritten with each checkout.

The way I see it is that you need to get all the things in luasetup.h
defined independently for each instance of the library and you need to
either give the library a different name or destination dir.

> > I couldn't find the equivalent for gcc's "-include" using nmake (MS's
> > compiler). Does anyone know if *all* compilers have this capability? I
> > assume yes?
> I really fear that most of win32 compilers do not have such option: I cou=
ldn't find it for
> CL (MSVC's compiler) nor for BCC32 (borland's one)...

That's a shame, I was hoping I missed it.

> > This should be pretty self explanitory. We could be less strict and
> > just #include a default luasetup.h
> I think that on win32 we should always use a default luasetup.h; if the n=
umber of options
> is not too big (say, < 16) we could use options in the makefiles: USE_FL,=
 USE_STC, etc...
> So that instead of editing setup.h for wxLua, the user would just need to=
 call:
>
> nmake -fmakefile.vc USE_FL=3D1 USE_STC=3D1
> to override the USE_FL=3D0 & USE_STC=3D0 defaults.

DOS only lets you have command lines < 256 chars IIRC. This can be
used up pretty quickly, but would work though.

> > We also need to do the same for the output library path and name, so
> > people can override them on the commandline or their own Makefiles for
> > their project.
> why would user need to override the output library name ?
> Also, the output path should be the usual wxLua/lib...

To have two different compiled versions of lib_wxluabind, see above.

Regards,
    John Labenski

Re: [Wxlua-users] wxLua Compiles and works in Linux

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

Hi,

John Labenski wrote:
> On 11/20/05, John Labenski <jla...@gm...> wrote:
> 
>>>NOTE: where do we want to install wxLua libraries and headers on unix ?
>>>$PREFIX/lib and $PREFIX/include seem a nice place for me, but we can consider also
>>>$PREFIX/lib/wxlua and $PREFIX/include/wxlua, specially if our lua headers/libs could give
>>>problems to other builds of lua installed in the same prefix...
>>
>>I guess we need to put them in $PREFIX/wxlua so the user just does -I
>>$PREFIX/wxlua in their Makefiles if they install it and or just -I
>>path/to/wxlua/modules if they didn't and it'll work both ways.
> 
> 
> Sorry should be
> 
> eg.
> modules/lua/include/*.h
> modules/wxbind/include/*.h
> modules/wxlua/include/*.h
> modules/wxluadebug/include/*.h
> modules/wxluasocket/include/*.h
> 
> go to
> $PREFIX/include/wxlua/lua/include/*.h
> $PREFIX/include/wxlua/wxbind/include/*.h
> $PREFIX/include/wxlua/wxlua/include/*.h
> $PREFIX/include/wxlua/wxluadebug/include/*.h
> $PREFIX/include/wxlua/wxluasocket/include/*.h
> 
> It's a little weird, but for the above reason I think it has to be this way.
ok, I agree this is best.

Francesco

Re: [Wxlua-users] wxLua Compiles and works in Linux

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

Hi,

John Labenski wrote:
> I don't know about the libs, maybe we can give them the same naming
> semantics as wxWidgets with our own version number so they won't
> conflct with anyone and then just dump them into the $PREFIX/libs.
> 
> For example in modules/wxlua/src/Makefile
> 
> WXLIBBASE  = $(shell wx-config --basename)
> WXRELEASE  = $(shell wx-config --release)
> 
> lib$(WXLIBBASE)_wxlua-$(WXRELEASE)
>    = libwx_gtk2ud_wxlua-2.7.so.1.5.0
> 
> LIBVERSION_CURRENT=1
> LIBVERSION_REVISION=5
> LIBVERSION_AGE=0
> 
> Where the 1.5.0 are just currently arbitrarily defined in
> modules/wxlua/src/Makefile.
ok, then let's go for a naming rule like the one for wx.


> How can we define these to be available
> for both the Makefiles and also the C++ code so we don't have to have
> them defined over and over again?
I couldn't found any way to do that. In *all* my project I have the project version 
defined _at least_ in 3 places:

1) the bakefile
2) the configure.ac
3) an header file

and I have to manually update them. However many project adopt a script to do that 
automatically...


>>PS: I added wxLua link to wikipedia page for wxWidgets; I wonder if
>>1) we should move the page which is currently at http://www.luascript.thersgb.net/ to
>>http://wxlua.sourceforge.net
>>  or
>>2) make a redirection from http://wxlua.sourceforge.net to http://www.luascript.thersgb.net/
> 
> 
> Can we have it point to both? We need to make a release once we get it
> to compile everywhere. Maybe in the next month.
Ops; I was not clear; the wikipedia page points to both the pages but that's a secondary 
issue. I meant to say that I think it's confusing for the user to see two websites with 
two different versions of wxLua.
So I'd like to go for 1) + a little restyling of the index page.

This would also make wxLua website a "standard" wxWidgets language binding next to:

http://wxperl.sf.net
http://wxruby.sf.net
http://wxbasic.sf.net
etc

Francesco

Re: [Wxlua-users] wxLua Compiles and works in Linux

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

Hi,

John Labenski wrote:
>>but for some reason, internal.cpp includes luasetup.h.in:
>>#include "../../../bindings/wxwidgets/luasetup.h.in" // get the base library setup parameters
>>which instead has a:
>>#define wxLUA_USE_FL 1
> 
> 
> I think the solution to making it possible to have multiple version of
> the wxlua bindings for different projects lies in making the compiler
> include luasetup.h for us.
This is not a "standard" solution; rather that, I'd prefer to use the same system adopted 
for wxWidgets: on win32 they provide a default setup.h which can then be customized by the 
user before compiling.
On unix a setup.h is generated from setup.h.in using the values of the --enable-xxx features.


> In modules/wxbind/src/Makefile I've done this.
> 
> WXLUASETUP = luasetup.h
> ...
> .cpp.o:
>         $(CXX) -include $(WXLUASETUP) -c $(CXXFLAGS) $(APPEXTRADEFS)-o $@ $<
> 
> so when you run
> $make WXLUASETUP=../path/to/your/luasetup.h
> you can use your own luasetup.h file.
> 
> I couldn't find the equivalent for gcc's "-include" using nmake (MS's
> compiler). Does anyone know if *all* compilers have this capability? I
> assume yes?
I really fear that most of win32 compilers do not have such option: I couldn't find it for 
CL (MSVC's compiler) nor for BCC32 (borland's one)...



> This should be pretty self explanitory. We could be less strict and
> just #include a default luasetup.h
I think that on win32 we should always use a default luasetup.h; if the number of options 
is not too big (say, < 16) we could use options in the makefiles: USE_FL, USE_STC, etc...
So that instead of editing setup.h for wxLua, the user would just need to call:

nmake -fmakefile.vc USE_FL=1 USE_STC=1

to override the USE_FL=0 & USE_STC=0 defaults.



> We also need to do the same for the output library path and name, so
> people can override them on the commandline or their own Makefiles for
> their project.
why would user need to override the output library name ?
Also, the output path should be the usual wxLua/lib...


> So... the one question remains, do all compilers support something
> equivalent to gcc's "-include" directive? Also, can bakefile handle
> this sort of thing?
If an equivalente GCC option existed, bakefile could support it.
Unfortunately I think that about 90% of GCC options are too 'advanced' for other compilers 
(which would be nice to support anyway)...

Francesco

Re: [Wxlua-users] wxLua Compiles and works in Linux

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

On 11/20/05, John Labenski <jla...@gm...> wrote:
> > NOTE: where do we want to install wxLua libraries and headers on unix ?
> > $PREFIX/lib and $PREFIX/include seem a nice place for me, but we can co=
nsider also
> > $PREFIX/lib/wxlua and $PREFIX/include/wxlua, specially if our lua heade=
rs/libs could give
> > problems to other builds of lua installed in the same prefix...
>
> I guess we need to put them in $PREFIX/wxlua so the user just does -I
> $PREFIX/wxlua in their Makefiles if they install it and or just -I
> path/to/wxlua/modules if they didn't and it'll work both ways.

Sorry should be

eg.
modules/lua/include/*.h
modules/wxbind/include/*.h
modules/wxlua/include/*.h
modules/wxluadebug/include/*.h
modules/wxluasocket/include/*.h

go to
$PREFIX/include/wxlua/lua/include/*.h
$PREFIX/include/wxlua/wxbind/include/*.h
$PREFIX/include/wxlua/wxlua/include/*.h
$PREFIX/include/wxlua/wxluadebug/include/*.h
$PREFIX/include/wxlua/wxluasocket/include/*.h

It's a little weird, but for the above reason I think it has to be this way=
.

Regards,
    John Labenski