Re: [Bug-zile] Checking for Lua libraries

[Gary V. Vaughan]

Hi Reuben,

On 19 Sep 2011, at 04:16, Reuben Thomas wrote:
> Having just written, but not yet tested, an autoconf macro to check
> for Lua libraries, I realised that this is silly: Lua programs should
> be checking their libraries at load time. (It's not expensive, just a
> string compare in an assert.) However, for convenience, it is not
> unreasonable to put these checks in a separate file which can also be
> called conveniently by the configure script. How about that? In Lua it
> looks something like:
> 
> require "foo"
> assert (some_predicate (foo.version))
> ...
> 
> which is also a lot easier than trying to code even some particular
> test (e.g. "is a version in a particular range) in m4.
> 
> Having the separate file also makes it easy for distro packagers to
> find the package's dependencies, but I think there's no harm in always
> running the asserts, because they are (for any conceivably reasonable
> check) so cheap.
> 
> OK?

That seems like a fine idea as an *additional* run time check.  But,
the earlier any failure is diagnosed than the easier it is to figure
out how to fix it.

DRY dictates that you don't want to write the checks once in autoconf
and then again in lua, so I think a small parameterized function in
Lua seems like the best compromise - configure can call a harness
with library name and version ranges to be passed to the function, and
at runtime, Lua can call the same function again to make sure no-one
pulled the rug out from under its feet.

However, doesn't FFI obsolete all this in short order?  Since there
will be no separate Lua interface wrapped around the C libraries that
needs to be checked for compatibility... in which case we come back
to having to use M4 library checks at configure time to ensure the
underlying libraries are present.  So maybe, it's more sensible to
punt on any interim solution that will be obsoleted by the next round
of development anyway?

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)