[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: >[ANN] bitlib release 25
- From: "steve donovan" <steve.j.donovan@...>
- Date: Thu, 31 Jan 2008 13:47:19 +0200
Well, I tend to favour the barbarian approach - just hack out the code
and build it!
On Jan 31, 2008 11:06 AM, Duck <firstname.lastname@example.org> 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.