Re: Triumvirates

[Dimiter 'malkia' Stanev <malkia@...>]

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 TARGET_SONAME=libluajit.so 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
> applications.
> - 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.
>
> Dirk
> (who had a spare half-hour between knocking off work and supper)