Add dual-licensed support for building against gnulib/libposix

[rrthomas]

Luaposix currently relies on the POSIX support of the build host. gnulib provides much wider support for POSIX APIs, especially on older OSes which lack up-to-date support, and on Mingw where it is often lacking altogether; but also fixes many bugs on widely-used systems (in particular Mac OS X, but there are even some useful fixes for glibc):

http://www.gnu.org/software/gnulib/

The main problem is that gnulib is mostly GPLed (some of it is LGPLed, and a small part public domain); otherwise we could simply use it by default.

Hence this issue: I propose that:

a) luaposix be dual-licensed MIT/GPL (it might be possible to offer LGPL as well, as a useful subset of gnulib is available under LGPL, and gnulib's build tool allows LGPL'ed versions of modules to be selected; but it would be more work)

b) when a GPL build is made, gnulib is used. (This is pretty easy, just a question of adding gnulib to the build system along with a list of modules. The list could be updated whenever luaposix is extended, but that doesn't strictly have to be done, you simply don't benefit from extra portability/fixes if you don't update the list for newly added APIs.)

Finally, if a gnulib expert takes an interest in this issue, there's a potentially less invasive way to implement it: use libposix. (Explanation: gnulib is a source library; libposix is an builds the POSIX APIs into a standard binary library. However, libposix is still, I believe, experimental.)

Implementing this issue would enable luaposix users to get much greater portability and more robust functionality on a wider range of platforms if they can use the GPL, while retaining the flexibility to stick with the MIT license.

[gvvaughan]

Maybe no need to carry that lumbering gnulib beast around on our back after all... check this out:

https://github.com/sionescu/libfixposix

[rrthomas]

Looks dubiously small and unmaintained to me. And let's not think about (irrelevant) size but ease of use. gnulib requires autotools, that's its burden. But for that you get an awful lot of POSIX goodness. If libposix is (or becomes?) usable, there's nothing to carry at all.

[gvvaughan]

Unfortunately, I was the main driver for libposix, so I'm not sure it will happen at all now I've removed it from my TODO list :( That would certainly have been the ideal solution.

But, this is what actually bothers me:

$ cd ~/Projects/libposix--github--0
$ git clean -dfx
$ du -sh . gnulib slingshot ext/posix
 64M    .
 58M    gnulib
1.5M    slingshot
316K    ext/posix

...not the autoconfigury at all. Although I have a stdlib branch building (somewhat temperamentally) with just LuaRocks and a bit of glue, so I'm getting closer to ejecting all the autofoo from our Lua projects.

More experimentation required.

[rrthomas]

But WHY does it bother you?!

[gvvaughan]

<snark>
316K of actual functionality (and half of that is curses bindings) requiring 58M of support files, which are mostly not required in nearly all cases except museum pieces (and Windows I imagine), and another 1.5M of glue code to hook it all together? Bleh.

I'd much prefer 158K of actual functionality, with a few 10's of K in build goo, and linking against your own crummy non-posix libc is not luaposix's problem :-)

luarocks install luaposix should take a few seconds, not several minutes (maybe several hours if we had to run all of gnulib's configure on some lip-service posix host and then build all the fix up wrappers in the museum). if you need a shim to patch up your museum quality libc implementation, pass some flags to luarocks to link the shim in, or LD_PRELOAD after the fact. All outside of the scope of luaposix IMHO.
</snark>