[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: IUP 2.4, Lua 5.1 and Windows
- From: Antonio Scuri <scuri@...>
- Date: Wed, 28 Dec 2005 11:50:03 -0200
I first tried the compilation using the VisualStudio project
files, but there I noticed that the configuration only
contained the "DEBUG" build of the libraries. Because I
am considering using IUP "seriously" I wanted to have
both DEBUG and RELEASE versions of the libraries.
Yes, the project files are only there for debuging porposes.
So I decided to look at the TecMake way of doing things.
After installing TecMake I noticed that it wanted to
generate dependency information using gcc (this was
not required, but I wanted to make TecMake happy),
so I added gcc to my cygwin distribution.
You can set the USE_NODEPEND environment
variable, and it will ignore the dependencies.
When examining the TecMake config, I noticed that
it supported compiling the debug/release versions into
separate libraries, if I defined DBG and DBG_DIR variables
(by set DBG=1 and set DBG_DIR=1 in command shell)
before running tecmake.
Here I met a problem with TecMake setting the DBG_DIR changes
the TEC_UNAME to for example vc71d, but latter
the tecmakewin.mak compares the TEC_UNAME only
to vc6 vc7 vc71 or vc8. I fixed this
by adding comparisons also to vc71d etc.
I do not use DBG_DIR for a long time now.
That's probably because only the VC7 project
files are used for debugging. I also do not think
that DBG_DIR is a good solution in Tecmake. We
have to improve that in the future.
In order to compile I had to do some editing in im/src/make_uname.bat
and comment out the im_wmv target, because I
didn't want to install the related SDKs at this
time. I also dropped compiling Lua5 (instead of
Lua5.1) versions of some of the components, because I did not need them.
(But I suspect that I had to return some of them because something
important was not built, if I dropped them)
You did right. To comment the make_uname
script is the best way to build only what you want.
Next I experienced problems with bin2c generated
code it used the lua_dobuffer function, which doesn't exists in lua 5.1.
I replaced it with luaL_loadbuffer and lua_pcall (and some assert
calls, in order to make it easier to find out what went wrong....)
I did this by editing the bin2c code.
The LuaBinaries distribution of Lua 5.1
re-includes the bin2c to the distribution. But I
just added the file without checking the
compatibility (tsc tsc..). To build IUP I have to
fix bin2c for Lua 5.1 just like you did it. I'm
going to fix this for the 5.1 final release in LuaBinaries.
During the process I met some problems which required quite a lot
of time to track down. For example I suspect that at one point
I was using Lua5 compiled (Lua) binaries with my Lua51 executable,
this caused the Iuplua51 exe to exit mysteriously.
When building the 2.4 binaries I had to
rebuild sometimes because in some build I used
the wrong Lua binaries. To build for two versions
of Lua 5 was hard, but I had to make sure that
IUP will work with 5.0 and 5.1. For the next
version I hope to build only for 5.1 and simplify the make_uname scripts.
IUP is not simple to build because it has many
libraries and uses other libraries and depends a
lot on native libraries like Motif. That´s also
why we release many pre-compiled binaries. The
Tecmake way is always the best choice to build it
because of the make_uname scripts. It makes life
a lot easier. Sorry about the mess with Lua 5.0
and Lua 5.1, but if anyone has only Lua 5.0 then the build should be simpler.
Thanks for the feedback.