On Oct 26, 2011, at 21:20 , Dimiter 'malkia' Stanev wrote:
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?
All of this besides the last point is addressed when building with CMake, in LuaDist we can build using various compilers(MSVC, MinGW, Clang) for various targets (64bit, 32bit). Avoiding the MS provided runtimes is recommended and possible too. Environment variables do not need to be specified on Windows if the distribution carries all its dependencies. LuaDist does solve most of this and the binaries (intended to replace L4W once fully tested) are available here[1].
These questions are not easy to answer.
They are actually very easy to answer when you are willing to invest time to learn tools created exactly for this purpose.
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).
In my opinion this is also no issue. For example LuaDist modules can be manually built without any other dependencies by checking out the module source and setting up few CMake variables that modify LUA_CPATH/PATH and install behavior etc. You can tailor the build to your needs, include it in your product release process or cross-compile for you exotic platform of choice. You do not have to use the magic automated installer intended for desktop releases.
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.
From my point of view there is no difference, both are Unix-like system with GCC/Clang available. CMake works on both and we can generate build files for your IDE of choice. You can safely ignore the native package management if your distribution does not depend on any outside sources.
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
Already done in LuaDist, thanks to CMake its fully automated and portable.
pd
[1] https://github.com/LuaDist/Repository/downloads
