lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


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.

-- | humour, n.  unexpected recognition