demerphq wrote:
On 7/22/06, David Golden <[EMAIL PROTECTED]> 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
platforms,
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).
David
