IUP 2.4, Lua 5.1 and Windows

[epajarre@...]

After the recent IUP 2.4 release I decided to look at
it seriously. For this purpose I also wanted to compile
it myself. The rest of this email contains my experiences
with some suggestions which things could be changed in
the distribution. (Some of my suggestions are probably wrong
because I just did not notice how the issues should be
solved correctly). Anyways I marked my suggestions with
!!!!!!!!!!!!!!!!!!!!!


I am using VC++ .net 2003 (VC++ 7.1), but my setup differs
from the IUP/CD/IM default for example in that sense
that I prefer using static linking, but I also use the
multi threaded libraries. For compilation I downloaded the
Lua51 package and unpacked it beside the iup, im and cd directories.
(I have a separate directory for my normal Lua5.1 source code)

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.

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.

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.
!!!!!!!!!!!!

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)

!!!!!!!!!!
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.
!!!!!!!!!!!

I think that combined with some minor tweaks, like adjusting the tecmake 
to use the version of runtime libraries I wanted, that was what was 
needed to compile iup etc for my environment.


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.
I tracked this down to the pairs of iuplua_changeEnv and
iuplua_returnEnv these were used to set the Lua global environment
to the "iup" table and to restore the global environment.
They require that the Lua stack is in the same state when returnEnv
is called as it was after the changeEnv call.

With the incorrect binary version the stack was apparently not
matched which globbered the Lua global state, which then
"caused problems"...



		Eero Pajarre