- CUSTOM BUILD OPTIONS
- CUSTOM CONSTRUCTOR AND BUILD METHODS
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
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).
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 CPAN.pm affairs. In an ideal world, we would
./Build.PL time only, and walk the cpan-testers walk in case we are unsatisfied (namely,
exit(0) without creating
./Build, as per http://cpantest.grango.org/wiki/CPANAuthorNotes). 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.
Overloaded so as to also call "ACTION_buildXS".