Re: >[ANN] bitlib release 25

["steve donovan" <steve.j.donovan@...>]

Well, I tend to favour the barbarian approach - just hack out the code
and build it!

steve d.

On Jan 31, 2008 11:06 AM, Duck <duck@roaming.ath.cx> wrote:
>
> 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.
>
>