The following are Lua-based build systems[1]. They function similar to tools like make[2], SCons[3][4], CMake[5][6], Autotools[7], and CPAN.pm[8]. However, the tools or the build files are written in Lua.
- SCons-like systems
- LuaBuildBou - dependency build system (somewhat like SCons)
- [Lake] Bou has grown up and been renamed Lake
- [primemover] - small, portable, easy to deploy dependency build system (somewhat like SCons)
- [Bam] - (like SCons)
- [LuaIBS] - make-replacement written in Lua and C and using LuaFileSystem
- [Meique] - scons-like tool written in Lua and C++
- [Sweet Build] - a build tool written in C++ and Lua.
- [moonmake]
- [tmake] - a build tool written in C++ using lua as configuration files.
- Build script generators (like Autotools and CMake)
- [premake] - build script generator (like CMake but with Lua as the config language)
- [Hamster] - Build script generator for Lua with API derived from [scons]. It can generate Makefiles (GNU/BSD/nmake), build with scons, or build with no external tool.
- [makebuild.lua] rudimentary Lua makefile generator in < 100 lines of code.
- [9] - proof-of-concept rockspec to Makefile converter
- Other:
- [jamplus] - a derivative of Perforce Jam, with various enhancements like outputting Visual Studio IDE, Xcode, and Code
- [tundra] - Lua configuration languages produces a DAG consumed by a multithreaded C builder supporting quick incremental builds. notes: [11][12][13]
- CPAN-like systems
- LuaRocks - deployment Lua modules, including network fetch, automated build, installation, and management (like Perl CPAN)
- [LuaDist] - Modules are built using CMake. Also includes optional package management features like LuaRocks.
- Memoized build systems (like fabricate, memoize.py, fbuild, ...)
- See Also
The following are build systems that are not necessarily implemented in Lua but nevertheless have been used to build Lua related code:
Such build automation systems ([1]) cover topics such as
- Compiling code or other files. This involves a few parts:
- There is some configuration language that defines what is to be built and in what order. This could be in the form of a makefile. It may be expressed in a limited language specific to the problem domain, but since it can be necessary to make decisions on what and how to compile, some general purpose language features are useful such as variables, control structures, functions/macros, and string/list manipulation. Some systems use Python (as in SCons) or Lua for this. Even if your build system does not use Lua for the configuration language, you can still likely invoke a Lua interpreter from it.
- There may be some means of translating high level build descriptions in the configuration language (e.g. compile a shared library from a list of C files) into actual commands to be run (compiler command lines with switches). This can require knowledge of each supported toolchain, which may be built into the build tool or definable by the user. Some simpler build systems (e.g. make) don't directly provide this knowledge but leave it up to the user to input low-level build descriptions.
- There is some means of scheduling the commands to be run, including ensuring they run in certain order based on dependencies, queuing jobs to run in parallel on different CPU cores or machines, omitting commands if the target is up-to-date (based on time-stamps or checksums), and checking error results. This is typically deeply coupled with the actual running of the commands, like via os.execute or some more advanced platform-specific process control mechanism or job processor. The commands may be invoked within the configuration language (like SCons). Alternately, this work might be offloaded to another existing tool, as done by "makefile generators" (like Automake, CMake, or premake) which generate, for example, a makefile, ninja build description, or msbuild description for use separately in a subsequent build step. The makefiles may need to be regenerated if the dependencies change, and there are ways to insert this into the makefile itself. The dependency tree might to some extent need to be determined dynamically (e.g. C include files).
- There may be some means of platform detection (e.g. detecting the host compiler, libraries, and symbols available), like autoconf. This information is used for "translating high level build descriptions". Sometimes it is run as part of the build process, or (like in autoconf) it may be a step run before the build process and not rerun during incremental builds, assuming the platform doesn't change. The job processor may be required for this to do things like test compiles on the host platform (assuming not cross-compiling to a different target platform).
- Running tests (make test), deployment (make install), and packaging (e.g. .deb).
- Deploying and/or compiling dependencies--like LuaRocks, the deployment tool in LuaDist, and CPAN.
Concerns include
- Ease of deploying the build system. It's convenient if the build system is usually pre-installed (e.g. make), or easily installed (apt-get install cmake), or perhaps has a low footprint and ease of deployment or even bundled in your package (e.g. [primemover]).
- Familiarity. Learning, debugging, or maintaining an unfamiliar, non-standard, buggy, inflexible build system is not fun. It's tempting to write your own build system, but there is a cost.
- Platform support. Does the tool know how to build on your platform and toolchain?
- Generality. If your build invokes only custom commands (e.g. building web pages or images rather than C code), convenience in defining your own arbitrary rules (like in make) is more important than having extensive built-in toolchain support.
- Speed. How fast are incremental builds? Are parallel builds supported? Precompiled headers?
- Support for platform detection (like autoconf), if support for many platforms is desired.
- Configuration language.
- IDE integration, like in premake, CMake, or to a lesser extent [SCons].
- Reliability of the build process.
RecentChanges · preferences
edit · history
Last edited March 9, 2013 9:57 pm GMT (diff)
