>[ANN] bitlib release 25

[Duck <duck@...>]

One small complaint/suggestion...

...any chance of getting rid of the dread autoconf stuff?

I see that the new sources #include "config.h", which means that if you 
are incorporating this package into a deliverable build tree of your own, 
you are stuck with [a] having an environment in which the builder can run 
./configure and [b] stuck with requiring the builder to run ./configure.
(Running ./configure in advance defeats the whole purpose ;-)

This seems a complexity overload for what would otherwise be a single-file 
library. Surely the needed #defines can simply be guessed in the lbitlib.c 
file, and overridden by the builder, as required, with -Ds in the makefile 
(or equivalent)?

Autoconf stuff is generally fine on Linux, OK on Windows but only if you 
are using MSYS (meaning that MinGW alone is not enough), and a real pain 
on other platforms (WinCE phones, 16-bit land, and more).

I'd suggest that all lbitlib operations simply should be "softwired" to 32 
bits on all platforms (the longest standard CPU-flavoured int within a 
standard double's 53-bit reach), with the builder repsonsible for 
re#defining the necessary parts if he or she wants 16 bits, 48 bits, 64 
bits (which would need a bigger lua_Number), and whatnot.

It's great to have a simple, standard and effective bitlib but not worth 
it to introduce autoconf into one's build world...none of the other common 
libraries I use require it.