lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

I treat lua and luajit same way as linux kernel.

When comes to full blown GNU/Linux distribution, then it's outside the kernel.

I understand your problem, but having lua (I'm more interrested in luajit though) BINARY distribution, at least for Windows is tricky:

	- Which compiler should be used? Can different compilers be mixed?
	- Should both 32-bit and 64-bit be supported
- Should we link to KERNEL32.DLL directly, or old style MSVCRT.DLL, or new style SxS MSVCRxx.DLL, or something like Mozilla - MOZCRT? - Should we rely on environment variables, or side effects (SetCurrentDirectory for example on Windows that changes the way DLLs are found)
	- Should there be a mode for static linking?
- For dynamic linking should we leave all .dlls one by one, or merge them together?
These questions are not easy to answer.

It depends on how you would use luajit. For some it's from the command-line, but my goal is to use it as plugin for certain Adobe or Autodesk products - as such I cannot rely on dependent modules to be in specific places (/usr/bin, or c:/windows/system32, or whatever there is), they have to be "near" the plugin one. Also at some point I would need special build so that all .dll/.exe are made into one .dll/.exe and distributed this way (as long as the LICENSE allows).

And then OSX - Should it be based on macports, fink or homebrew? Or should it use the system installed ones? XCode? (thank god it's free again)

For Linux is probably easier - there are already well established systems, and maybe reusing them is better - apt/rpm/deb/whatever there is.

For now my goal is to treat everything locally, although I still rely on LUA_PATH and LUA_CPATH (but I'm going to change that).

I've found on all three major (for me) platforms ways to load DLLs relative to the places they are located.
	-- Windows - That's by default, unless SetCurrentDirectory() is used
	-- OSX - install_name_tool magic tool with @rpath, @executable_path
	-- Linux - -rpath with $ORIGIN magic

make -C $ROOT/src -j amalg BUILDMODE=dynamic TARGET_DYNXLDOPTS=-Wl,-rpath,'$$\ORIGIN' Q=

On 10/26/2011 9:01 AM, Dirk Laurie wrote:
Postings involving the following circle of ideas often appear on the list.

- Lua has no officially blessed library with hundreds of add-ons like
Python does.
- The initial exposure to Lua includes no WOW! graphics and/or sound
- The Lua interactive shell is very primitive compared to {ipython,…} — no GUI
   for program development.

There are at least three big projects in the direction of standard
module libraries:
Kepler, stdlib and Penlight.  There is at least one project in the direction of
synchronized module management: Luarocks.  There is the LfW collection for
Windows.  But none of them is 'official'.

What the community needs (maybe) is a sort of overall design and quaiity control
of module libraries.  Near-universal acknowledgment that a particular set of
modules, as painless to install on all platforms as is Lua itself, is canonical.

It is quite clear that we must not expect the Lua team to deal with
these issues.
Luiz and Roberto have both put substantial Lua add-ons on their sites with no
attempt to make them part of the 'official' Lua distribution.  Their task is to
keep the Lua core lean and healthy, and very well they do it too.

There have been suggestions of appointing a BDFL for overseeing a Lua module
library, all candidates however turning down the honour.

Now we have seen a development management model that works well: the one
in action for Lua itself.  A triumvirate of individuals with different
but compatible
talents.  A conservative policy of requiring unanimity before a
feature is added.

By contrast, most [ANN] items on lua-l are one-man efforts.  Sometimes, as in
the case of LuaJIT, that one man is a superman, but many others are pet projects
that die within a year.

Suppose there were similar triumvirates for module libraries, with a similar
conservative policy.  Maybe the reluctant BDFL's would be willing to shoulder
this shared responsibilty.  Then we might, we just might, see some consensus
emerging on which libraries are the one every Lua programmer should turn
to first.

(who had a spare half-hour between knocking off work and supper)