demerphq wrote:
On 7/22/06, David Golden wrote:
2) The Complex Problem: Dual XS/PP modules are not hard to do (e.g.
Params::Validate), but they do require robust compiler detection across
Im a little confused about this one. I can think of a few modules that
provide dual implementations that dont require robust compiler
detection. Whats wrong with

Are you set up to compile XS code [y/n]

And then install the XS only if they answer yes? Is this a case of
trying to come up with a high tech solution where a low tech solution
would be just as good?
I would consider the use of prompt() with a sensible default to be a
"robust" approach.


I suspect that ExtUtils::CBuilder::have_compiler() is likewise fairly
robust. At least, I hope so, if M::B is going to be a replacement for
needing make.

Assuming things about qr/?make/ is not robust (example from DateTime-0.31):
system( "$Config{make} test$Config{obj_ext}" )
Which, for Vanilla Perl, gives:
dmake: Error: -- Don't know how to make `test.o'
The approach in Params::Validate (and borrowed for version.pm) uses
ExtUtils::CBuilder, if installed, and otherwise tries manually against
the configured CC, rather than make:
system( "$Config{cc} -o test$Config{obj_ext} test.c" )
Which, as a fall-back, is hopefully a bit more portable. Frankly, I'm
not sure why it isn't just "$Config{cc} test.c", but I'm not very
compiler savvy.

These "high-tech" solutions seem fine to me if you want to default to
the XS version (which most anyone with a compiler is likely to want).

However, M::B *dependencies* have to use these techniques directly
instead of relying on M::B to provide have_c_compiler() (which just
wraps ExtUtils::CBuilder anyway).


Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 13 of 33 | next ›
Discussion Overview
groupmodule-build @
postedJul 18, '06 at 12:16a
activeJul 26, '06 at 7:09a



site design / logo © 2018 Grokbase