Hi all,
This is really just to start a discussion, first to identify any areas
of weakness and generally any impediments to taking over the world ;)
LR stretches over a wide range of operating systems, and generally we
should aim to make that as painless as possible. Windows poses its own
challenges, since it has no policies for things like where to put
external libraries. But even on Unix, there is a bewildering array of
places where things are to be found. I recently played with FreeBSD
(just for kicks) and discovered how Linux-centric my thinking really
is ;) It brings its own difficulties, since some common things like
wget and unzip are not part of the standard install. And the make it
comes with is the BSD barebones version, which cannot handle the
GNU-niverse extensions. (So then I saw the wisdom of it using 'gmake'
explicitly - another thing to grab). At least it has a package
manager! However, the Lua includes end up in
/usr/local/include/lua51, yet another variation on the old theme.
Generally, LR contains too many makefiles. This is particularly
irritating on Windows, since the corresponding Makefile.win is often
not present - and then it's an open question whether it's intended for
the MS cl compiler (nmake) or for mingw make. So extending the range
of the 'builtin' build type seems a useful thing. It occurred to me
that specifying the name of the built target (e.g.
build.modules.foo.name) explicitly could handle some irritating cases
(e.g. luasocket/core). (We might as well throw in a 'cflags' field
here for other special cases)
Finding external dependencies is still hit or miss. I think the
latest changes committed at least give the user more clues about what
to do next. One issue is that there is no standard place to put some
common packages, e.g. Tcl/tk. (Look at the ltcltk rockspec to see a
lament about this). One way to help this is to provide a list of
possible places (see [1] for one proposal)
What would be very cool is a way of encoding distribution-specific
hints. E.g. for ubuntu/debian, foo-dev, for fedora, foo-devel, etc.(
I know this puts an extra burden on the packager but we can all pitch
in here.)
My personal roadmap is sorting out some Windows issues, and making
things like build.install.* more generic (by using the appropriate
extension, .so or .dll if no extension is given). I'm also interested
in tools that generate rockspecs, e.g. rockspecifier and a new little
project that provides a DSL for generating rockspecs and handling the
often confusing topic of per-platform overrides in another way:
project("foo","1.0")
C.module.foo "foo.c" :when "win32" :add "winutil.c"
I'm also working on a Lake rock, and have an experimental Lake
back-end. Can't say it will take the world by storm, but it does give
a clean alternative to makefiles that can be made a dependency of a
package.
steve d.
[1] See the ltcltk rockspec in
https://github.com/stevedonovan/luarocks/commit/393acc7ef9f1c69a81ee8bfb1522d1c972285da9
external_dependencies = {
TCL = {
header = "tcl.h,tk/tcl.h,tcl/tcl.h"
}
}
(The commit history is borked at this point; mosey around for the
actual code changes)
_______________________________________________
Luarocks-developers mailing list
[email protected]
http://lists.luaforge.net/cgi-bin/mailman/listinfo/luarocks-developers
