Author image Dominique Quatravaux



Provides the CFLAGS to pass to the compiler so that it finds OpenSSL header files etc. Default is to query pkg-config, or failing that, to use no particular CFLAGS.


Provides the LDFLAGS to pass to the linker so that it finds OpenSSL libraries etc. Default is to query pkg-config, or failing that, to use only -lcrypto -lssl.


Enables "full_debugging" in Crypt::OpenSSL::CA::Inline::C while running ./Build test. Setting the FULL_DEBUGGING environment variable to 1 has the same effect, however the latter is not possible eg from the Perl debugger. Implies use_blib=0 (see My::Module::Build).


resume ()

Overloaded so as to set a flag indicating that we are running from ./Build and not Build.PL. This flag in turns tells "fail_and_suggest_switches" to fake an "OS unsupported" situation so as to fool CPAN::Reporter into not sending bug reports to the author.

Design note/complaint: saying that this is inelegant is one bit of an understatement, but it is the best I could come up with in the current state of affairs. In an ideal world, we would ->check_openssl_version_number() at ./Build.PL time only, and walk the cpan-testers walk in case we are unsatisfied (namely, exit(0) without creating ./Build, as per Unfortunately we absolutely need a Perl module to check that OpenSSL version! (Currently we use Inline::C, but that is immaterial: making that Alien::OpenSSL or whatever wouldn't suppress the dependency, only move it elsewhere.) The only alternative would be to distribute our C-compiling infrastructure along with Crypt::OpenSSL::CA in the inc/ sub-directory, but these things tend to have a huge dependency trail (well, except for Devel::CheckLib, which unfortunately is too simple to do version checking).

Executive summary: I thought of the alternatives, and they don't work.

ACTION_build ()

Overloaded so as to also call "ACTION_buildXS".

ACTION_buildXS ()

Builds the XS modules for distribution into "arch" in blib. Calls "check_openssl_version_number".