dkg has asked for the wisdom of the Perl Monks concerning the following question:

i'm contributing the the Crypt::GCrypt perl bindings for libgcrypt. Certain old versions of libgcrypt are simply buggy, and will guarantee a test suite failure for the perl module. I'd like to refuse module compilation entirely when those versions are present (and print a helpful error message explaining why users should upgrade). What's the best way to do that?

I have a very simple C program written that could be compiled with the same flags used by the translated GCrypt.xs; It returns a 1 for "bad version" or 0 for "good version".

Is there a standard way to have the perl Makefile.PL step build and run this program before emitting a Makefile? Or should i look at some other way to check this information? Or should i just let the test suites fail without any other checking?

Replies are listed 'Best First'.
Re: Testing for C library status at perl binding build time?
by Corion (Patriarch) on Dec 17, 2009 at 18:09 UTC

    I'd look at how Net::Pcap does it - it does some testing and precompilation of small programs before emitting the real Makefile. Also, Net::Pcap builds on Windows, so it likely knows about non-gcc compilers and how to treat them.

Re: Testing for C library status at perl binding build time?
by jettero (Monsignor) on Dec 17, 2009 at 18:10 UTC

      We're already using Devel::CheckLib, but it only checks for the existence of the library. I don't see a way to make it check the return value of a given function call when compiled against that library.

      Have i missed something from the Devel::CheckLib documentation?

        The current stable version (0.06) doesn't support this, but it seems that the current developer version, 0.699_001, supports supplying your own function body to be compiled and/or run. And as you're supposed to bundle Devel::CheckLib with your module anyway, using the developer version is just as good as using the stable version.