[ANNOUNCE] Lua 4.1 (work4)

classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] Lua 4.1 (work4)

Thatcher Ulrich
On Feb 18, 2002 at 11:26 -0300, Luiz Henrique de Figueiredo wrote:
> 
> Only if you want to do something other than the default. And it's a
> config file, not the Makefile. As far as I can tell, the Makefile is
> pretty standard.  If not, I welcome suggestion on making the
> Makefiles more standard and portable.

I like the Makefiles as they are, but I think one improvement to make
them more Win32-friendly would be to use macros to specify the file
extensions, because the windows conventions are different:

	.o --> .obj
	.a --> .lib
	.so --> .dll

I took a stab at making the Makefiles compatible with "nmake", which
is the version of make that ships with MSVC.  Unfortunately, I think
it's difficult to achieve nmake/GNU Make compatibility; for example
nmake requires a "!" in "!include $(LUA)/config", and the "cd include;
$(MAKE) $@" doesn't work at all, etc.

Personally, I use cygwin under Win32 to make it tolerable, and stock
Lua builds fine with cygwin using the GNU tools and the Unix file
extension conventions.  However, often I need to develop using MSVC
(Microsoft Visual C/C++), to make it easy to distribute executables,
and to be compatible with projects that are Win32-specific.  In these
circumstances I like to use GNU make, but calling the MSVC compiler
and using Win32 file extension conventions.  These are things that can
be accounted for in lua/config.

So, I've made Makefiles for Lua-4.1-work4 which can easily be adapted
to Win32/MSVC by editing lua/config.  I've uploaded it to the wiki as
a PowerPatch so people can have a look at it:
http://www.lua-users.org/wiki/PowerPatches .  By default it should not
affect the Unix build at all (if it does, then that's a bug -- let me
know).  Under Windows, if you have GNU make, you can just edit the
"config" file and build with MSVC by doing "make".  I left comments
for Windows users in the "config" file, as well as an explanation in
the "INSTALL" file.

I'd love to see this get folded into the standard Lua distribution,
since I think it would help Win32 folks in general, without hurting
anyone else.

TODO: I didn't experiment at all with the .so support in the
makefiles.  I'm pretty sure that can be supported without too much
trouble, but I just didn't have time for it this morning.  Also, I
didn't do anything with "make install" under Windows; I'm not sure
what, if anything, would make sense there.

-- 
Thatcher Ulrich <[hidden email]>
http://tulrich.com

Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] Lua 4.1 (work4)

Jay Carlson
In reply to this post by John D. Ramsdell-3
On 18 Feb 2002, John D. Ramsdell wrote:

> [hidden email] (Erik Hougaard) writes:
> 
> > But the main problem is still, that Lua is two different things to different
> > people. We have the script guys who just want to download/install/use, and
> > then we have the embedded people (including my self) who embeds Lua into all
> > sort of different thing and we dont care about makefiles cause we need it to
> > be part of our own build system, so we are most more interested in keeping
> > Lua 100% ANSI-C without tons of preprocessor defines that would collide with
> > the application that we embed Lua into.
> 
> For embedded people, shouldn't it be possible that a Lua header file
> and a shared library are placed in some appropriate public places.
> Embedded usages of Lua compile source files using the interface
> declared by the public header file, and then link in the shared
> library at runtime.  In this model, the script engine is just another
> consumer of the shared library.  It is compiled by including the
> public header file, and it links to the shared library at run time.
> It's no different than any other embedded user of the library.

I think I see a miscommunication here.  The word "embedded" is being
used in two different ways.

Embedding Lua into applications, in the way that Tcl advocated.
Typically, you're on a conventional workstation.  Shared libraries are
appropriate if you have a deployment environment that can cope with
them.  Some people want to ship as a single executable, for a number
of reasons (some good, some bad).  For example, for a long time
Windows installers and practices in using them discouraged the
deployment of DLLs except when unavoidable.  And when shipping
cross-distro Linux binaries, there are often pressures to link as much
as possible statically, to avoid package dependencies.

Using Lua in embedded systems.  Most embedded systems have
environments that have little in common with the typical workstation.
For instance, I can almost see using Lua in a boot monitor.  To build
such a thing, there's a lot of custom work in the production of linker
scripts and ROM imaging output to get an executable. And since there
may not even be *files*, shared libraries are unlikely.

> In any event, the use of autoconf could be easily used to create this
> setup.  Building and installing shared libaries is well supported.
> There should be no conflict between embedded and scripting Lua users.
> Embedded poeple should be able to use Lua as a shared library if that
> best suits their needs.  Or they may simply want to copy the sources
> into there source tree.  Whatever works...

Shared libraries on Unix are a huge pain to get right if you're trying
to support more than just Linux, *BSD, and Solaris.  These days, many
new projects delegate the details of shared library production to GNU
libtool....

Jay


Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] Lua 4.1 (work4)

Thomas Wrensch-2
In reply to this post by Thatcher Ulrich
A brief comment on this thread that concerns Lua's (lack) of use of the
auto config utility. It is somewhat off-topic, but I think it might show
how a subset of Lua users might feel about this issue:

First, a cavet: I am not a make expert. I am not a make fan. Make is, at
best, a necessary evil.

I have had difficulty making the lua make files work on both Win32 and
SunOS 5.8. I finally found an easy work-around on Win32 for VC++ which I
will get to in a bit.

I did finally get Lua compiled on SunOS after much fiddling and
swearing. When I had to recompile it on a different SunOS machine I
decided to try the same workaround I used for VC++, and it worked like a
charm. So for those of you who have trouble using make and don't mind
using a really dumb approach to solving the problem try this:

Put all the lua source and header files in one directly. This includes
lua.c, the library files, the files from the include directly, but NOT the
files from luac or the etc. files. In visual C++ make a project in that
directory and add all the files to the project. Hit build all. Done.

On most Unix systems you can go cd to the directly and do

   cc *.c -lm

And you're done. (the executable is in a.out, so you have to rename it).

Ugly, but effective. No make files, no config files, and you have a
stand-alone lua executable. Of course if your using lua as an embedded
language in a larger application, this probably wont work.

So, to bring this back to the topic of this thread, I expect there are
many Lua users, particularly those who use lua as a scripting language,
who would benifit from an easy way to compile Lua on their system. The
open source "standard" being discussed here probably isn't what's
needed. Maybe just someone coming up with some clear step-by-step
directions for those who do not regularly use tools like make and
autoconfig.

And please don't say that users who don't know these tools shouldn't use
Lua. Lua is a much higher level language than C or C++ and its users may
be quite expert programmers who just don't make much use of lower-level
languages.

   - Tom Wrensch


On Mon, 18 Feb 2002, Thatcher Ulrich wrote:

> On Feb 18, 2002 at 11:26 -0300, Luiz Henrique de Figueiredo wrote:
> > 
> > Only if you want to do something other than the default. And it's a
> > config file, not the Makefile. As far as I can tell, the Makefile is
> > pretty standard.  If not, I welcome suggestion on making the
> > Makefiles more standard and portable.
> 
> I like the Makefiles as they are, but I think one improvement to make
> them more Win32-friendly would be to use macros to specify the file
> extensions, because the windows conventions are different:
> 
> 	.o --> .obj
> 	.a --> .lib
> 	.so --> .dll
> 
> I took a stab at making the Makefiles compatible with "nmake", which
> is the version of make that ships with MSVC.  Unfortunately, I think
> it's difficult to achieve nmake/GNU Make compatibility; for example
> nmake requires a "!" in "!include $(LUA)/config", and the "cd include;
> $(MAKE) $@" doesn't work at all, etc.
> 
> Personally, I use cygwin under Win32 to make it tolerable, and stock
> Lua builds fine with cygwin using the GNU tools and the Unix file
> extension conventions.  However, often I need to develop using MSVC
> (Microsoft Visual C/C++), to make it easy to distribute executables,
> and to be compatible with projects that are Win32-specific.  In these
> circumstances I like to use GNU make, but calling the MSVC compiler
> and using Win32 file extension conventions.  These are things that can
> be accounted for in lua/config.
> 
> So, I've made Makefiles for Lua-4.1-work4 which can easily be adapted
> to Win32/MSVC by editing lua/config.  I've uploaded it to the wiki as
> a PowerPatch so people can have a look at it:
> http://www.lua-users.org/wiki/PowerPatches .  By default it should not
> affect the Unix build at all (if it does, then that's a bug -- let me
> know).  Under Windows, if you have GNU make, you can just edit the
> "config" file and build with MSVC by doing "make".  I left comments
> for Windows users in the "config" file, as well as an explanation in
> the "INSTALL" file.
> 
> I'd love to see this get folded into the standard Lua distribution,
> since I think it would help Win32 folks in general, without hurting
> anyone else.
> 
> TODO: I didn't experiment at all with the .so support in the
> makefiles.  I'm pretty sure that can be supported without too much
> trouble, but I just didn't have time for it this morning.  Also, I
> didn't do anything with "make install" under Windows; I'm not sure
> what, if anything, would make sense there.
> 
> -- 
> Thatcher Ulrich <[hidden email]>
> http://tulrich.com
> 


Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] Lua 4.1 (work4)

CRIBBSJ
Tom Wrensch wrote:

So, to bring this back to the topic of this thread, I expect there are
many Lua users, particularly those who use lua as a scripting language,
who would benifit from an easy way to compile Lua on their system. The
open source "standard" being discussed here probably isn't what's
needed. Maybe just someone coming up with some clear step-by-step
directions for those who do not regularly use tools like make and
autoconfig.

Amen!


And please don't say that users who don't know these tools shouldn't use
Lua. Lua is a much higher level language than C or C++ and its users may
be quite expert programmers who just don't make much use of lower-level
languages.

  - Tom Wrensch


Well put!

Jamey.

Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] Lua 4.1 (work4)

Luiz Henrique de Figueiredo
In reply to this post by Luiz Henrique de Figueiredo
>Put all the lua source and header files in one directly. This includes
>lua.c, the library files, the files from the include directly, but NOT the
>files from luac or the etc. files. In visual C++ make a project in that
>directory and add all the files to the project. Hit build all. Done.

This is explained in INSTALL.
Without moving any files at all, you can do this directly:

 cc -O2 -o bin/lua -Iinclude -Isrc src/*.c src/lib/*.c src/lua/*.c -lm

and you get bin/lua but no libraries.
If you want libraries as well, then do this instead:

 cd src; cc -O2 -c -I../include *.c; ar rc ../lib/liblua.a *.o
 cd lib; cc -O2 -c -I../../include *.c; ar rc ../../lib/liblualib.a *.o
 cd ../lua; cc -O2 -o ../../bin/lua -I../../include *.c ../../lib/*.a -lm

Similar command lines should work for Windows, if you know how to run your
compiler in the command line (which I doubt most users do).

Should this be explained in INSTALL?
--lhf

Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] Lua 4.1 (work4)

Thatcher Ulrich
On Feb 18, 2002 at 04:04 -0300, Luiz Henrique de Figueiredo wrote:
> >Put all the lua source and header files in one directly. This includes
> >lua.c, the library files, the files from the include directly, but NOT the
> >files from luac or the etc. files. In visual C++ make a project in that
> >directory and add all the files to the project. Hit build all. Done.
> 
> This is explained in INSTALL.
> Without moving any files at all, you can do this directly:
> 
>  cc -O2 -o bin/lua -Iinclude -Isrc src/*.c src/lib/*.c src/lua/*.c -lm
> 
> and you get bin/lua but no libraries.
> If you want libraries as well, then do this instead:
> 
>  cd src; cc -O2 -c -I../include *.c; ar rc ../lib/liblua.a *.o
>  cd lib; cc -O2 -c -I../../include *.c; ar rc ../../lib/liblualib.a *.o
>  cd ../lua; cc -O2 -o ../../bin/lua -I../../include *.c ../../lib/*.a -lm
> 
> Similar command lines should work for Windows, if you know how to run your
> compiler in the command line (which I doubt most users do).
> 
> Should this be explained in INSTALL?

Hm, maybe even a build-msvc.bat?  build-borlandc.bat,
build-mingwin.bat, etc.  These could all just be put on the wiki, to
avoid having to maintain them yourself (on the other hand, downloading
a .bat from the wiki is just one more confusing thing for a first-time
user).

-- 
Thatcher Ulrich <[hidden email]>
http://tulrich.com

Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] Lua 4.1 (work4)

Erik Hougaard
In reply to this post by Luiz Henrique de Figueiredo
----- Original Message -----
> Similar command lines should work for Windows, if you know how to run your
> compiler in the command line (which I doubt most users do).

Aaarrgh... Give us some credit will ya :-)
/e


Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] Lua 4.1 (work4)

Eric Tetz-2
In reply to this post by John D. Ramsdell-3
--- "John D. Ramsdell" <[hidden email]> wrote:
> The point of using autoconf is that it can be used to automatically
> generate the content of the config file.  There is no need to ask that
> humans edit the config file.  Let autoconf probe the environment and
> then write the config file. 

So add a bunch of complicated machinery to make Lua easier to build on the one platform that it
already includes a makefile for?

I've always appreciated the fact that, like Lua itself, the distro is clean and simple. The make
files are tiny and easy to read. There are no superfluous files.  Polluting the distro with
autoconf would be tragic.

Cheers,
Eric



__________________________________________________
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
http://sports.yahoo.com

Reply | Threaded
Open this post in threaded view
|

Re: autoconf (Re: [ANNOUNCE] Lua 4.1 (work4))

Andy Tai-2
In reply to this post by Jay Carlson
I would to mention that a patch to add autoconf
support to the Lua distribution exists at

http://www.atai.org/lua/lua_autoconf_patch.gz

It was against an earlier version of Lua, but I would
guess it also works for the latest 4.1 "work" version.

__________________________________________________
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
http://sports.yahoo.com

Reply | Threaded
Open this post in threaded view
|

Re: autoconf

Juergen Fuhrmann
>  Mon, 18 Feb 2002 14:44:53 -0800 (PST)
>  Andy Tai <[hidden email]> wrote:
>
>  I would to mention that a patch to add autoconf
>  support to the Lua distribution exists at
>  
>  http://www.atai.org/lua/lua_autoconf_patch.gz
>  
>  It was against an earlier version of Lua, but I would
>  guess it also works for the latest 4.1 "work" version.
>  

So  this may  be  the way  to  go: someone  supports  this patch,  and
autoconf writes the makefile config, and  this stuff is put on the Lua
wiki or so.

My opinion on  autoconf: this stuff has been made to  find out the way
how lots of  non-ANSI features are available. Lua  _is_ ANSI, so there
is no need to use autoconf.  The only thing I have to find out for Lua
is which compiler to  use. If there is more than one  on the system, I
anyway will have to tell this even to configure.  

I just tried

cc -O2 -o bin/lua -Iinclude -Isrc src/*.c src/lib/*.c src/lua/*.c -lm

from lhf's post,  and it works. No more to say. May be you provide a
dummy configure sript, this would resolve the problem ;-)


I am compiling Lua in an automated configuration processs, and I do so
with other,  autoconf'ed packages. When it comes  to installation into
non-standard places (what  I am doing) I don't  see any advantage from
autoconf as anyway I have to  fiddle with the flags to autoconf to get
it to  work. configure/make/make install  only works when I  put stuff
into /usr/local  the standard way. In  any other situation,  I have to
look what make install really does in order to get things right.

So please do not force the use of autoconf, may be for people who like
configure/make/make install someone could maintain a patch on the wiki.


Juergen


Juergen Fuhrmann
                             Numerical Mathematics & Scientific Computing
               Weierstrass Institute for Applied Analysis and Stochastics
   Mohrenstr. 39 10117 Berlin    fon:+49 30 20372560   fax:+49 30 2044975
http://www.wias-berlin.de/~fuhrmann        [hidden email]



12