bitlib and autotools

[Reuben Thomas <rrt@...>]

Hi,

Shmuel Zeigerman drew my attention to Duck's question about config.h. 
Thanks, Shmuel. (I don't normally read lua-l, so please either copy me in 
such messages or even better use the trackers on LuaForge.)

I looked into it and found that config.h is not actually currently needed, 
so I've checked in a change to CVS to not use or generate it. Duck, would 
you have a look at it and tell me whether it does what you want now?

Duck writes:

> 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.

That would really annoy maintainers for Debian and *BSD, for starters, who 
would have to hard-wire the settings for each platform. I'd much rather make 
life easy for most users (just ./configure && make as normal), and possible 
for the rest than reduce everyone to having to check and possibly edit some 
header file. And it's not just byte widths: the configure script takes care 
of finding Lua, specifying build options and, via libtool, the system- 
dependent methods of building libraries. It saves time for me (I only have 
to write it once), and for most users (the build configures itself).

Duck writes:

"This seems a complexity overload for what would otherwise be a single-file 
library."

On the contrary, using autotools makes things simpler. It simplifies 
development, test and distribution for me, and building for most users. 
Complexity is not measured in bytes, it's measured in keystrokes.

Anyway, let me know whether the CVS version of bitlib is now better for you, 
and if so I'll release it.

--
http://rrt.sc3d.org/ | humour, n.  unexpected recognition