[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: >[ANN] bitlib release 25
- From: Duck <duck@...>
- Date: Thu, 31 Jan 2008 20:06:44 +1100 (EST)
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
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.