On Wed, Oct 6, 2010 at 8:51 AM, Jerome Vuarand <[email protected]> wrote:
> What would happen if I try to install a C module as source on a
> luarocks installation without C compiler? ...
> The 'fallback' could even be the name of a Lua file containing a pure
> Lua implementation of the C module.
I recall researching the ways various ports/package systems handle
optional dependencies for LuaDist [1]. Some of the methods used are
(1) Conditional dependencies. A depends on B only if condition C is
true (e.g. where C may be a predicate about the system platform).
if ARCH == "Windows" then
dependencies["luadist_utils"] = ">=0.1"
end -- though perhaps written more declaratively.
Note, however, that B rather than A may be better able to evaluate condition C.
(2) Explicit package options. These are like #1 but with C explicitly
set as a variable by the user and possibly controlling build options
(rather than just dependencies). This is sort of like the feature
flags passed to "configure".
if USE_GTK then
dependencies["gtk"] = ">=1.0.0"
end
if INSTALL_DOC then .....build documentation......
MacPorts' "variants" are similar:
variant gnome requires glib {
configure.args-append --with-gnome
depends_lib-append port:gnome-session
}
(3) OR (conjunctive) dependencies, in addition to just AND
dependencies. OR dependencies can be satisfied if at least one of the
dependencies in the given list is satisfied.
dependencies = {
lua = ">= 5.1",
OR {
openglut = ">= 0.6.3",
freeglut = ">= 2.4.0",
glut = ">=3.7.6"
}
}
Optionally, you can make "metapackages" that exist only for the
purpose of defining OR dependencies.
Debian .deb succinctly combines #1 and #3 and allows build
dependencies to differ from deployment dependencies:
Depends: libc6 (>= 2.2.1), exim | mail-transport-agent
Build-Depends: foo [!i386] | bar [!amd64]
(4) Virtual packages / provides. Rather than module A saying that it
needs B or C, have B and C state that they provide some interface D
and have A depend on D. In this way, A's dependencies are not fully
controlled by A. RPM has this.
For example, Lua and LuaJIT would both provide the lua virtual package
and modules depending on lua would not need to explicitly mention
LuaJIT in their dependencies. This also nicely handles custom Lua
interpreters (e.g. LNUM patched Lua).
(5) Optional dependencies.
optdepends=('cups: printing support')
-- ArchLinux's way of saying that printing support is optional and
its dependency may be skipped.
(6) File dependencies. Here, a package depends on a particular file
existing on the user system rather than some other particular package.
"lib:libX11.6:xorg",
-- MacPorts' way of saying to search for the system library
-- file libX11.6.so and failing that install the port package "xorg".
The analysis of package systems in [2] may also be of interest.
[1]
http://sourceforge.net/mailarchive/message.php?msg_id=4A9A91ED.4090103%40gmail.com
[2] http://www.mancoosi.org/edos/index.html
_______________________________________________
Luarocks-developers mailing list
[email protected]
http://lists.luaforge.net/cgi-bin/mailman/listinfo/luarocks-developers
