On Tue, May 24, 2011 at 11:06 AM, Moritz Wilhelmy <[email protected]> wrote: > FreeBSD has fetch, NetBSD's tnftp supports downloading via http and ftp. You > could default to these when installing luarocks on the respective system.
Actually, the standard LuaRocks configure will detect and use fetch. > Also note that the BSD implementation of tar supports a wider range of formats > (because it's a frontend to BSD's libarchive) and can extract zip archives > just > fine OK, that's fine; it's just that LuaRocks currently has a unzip dependency which could be generalized (for instance, on Windows everything is done with 7zip) > Also note that GNU make is fairly portable (and as you already pointed out, > available on the BSDs as 'gmake') Yes, at first I did not understand why LuaRocks defaulted to 'gmake' and not the local make, but then I noticed that some pretty simple makefiles (e.g. md5) require GNU features. It's overkill, and as you say, the problem is mostly non-portable makefiles. >> At least it has a package manager! > > Come on... Was I complaining? I found the FreeBSD package manager easy to use after a few tries. The comment is about certain popular operating systems which don't have such a nice feature. > Not at all. In fact, lua installed via "make install" lands there as well. BSD > separates between base system and 3rd-party software. I'd assume you'd have > read about it before running into it? Of course these strategies are up to the OS packagers. Debian uses /usr/include/lua5.1. I am not at all bothered by such differences; that's why there is a configure script. Perhaps you think I was complaining about FreeBSD being 'different' but I'm sufficiently grown-up to know that Linux is not Unix (in fact, strictly speaking it isn't, unlike OS X) > I disagree. Makefiles are not the problem, unportable Makefiles are. For a definition of 'portable' that means 'works on anything that looks like Unix'. > And it will always be. You can never be sure if tcl/tcl.h is really provided > by > Tcl and if /usr/bin/perl really is perl. Fair enough. But the idea is to capture the common patterns. I admit that it takes LR out of its well-defined mission to deliver working Lua modules, but I am curious about how this process can be improved. steve d. _______________________________________________ Luarocks-developers mailing list [email protected] http://lists.luaforge.net/cgi-bin/mailman/listinfo/luarocks-developers
