well, i only maintain Compress::Bzip2, not CPANPLUS.
Compress::Bzip2 is a perl xs module. you cannot install it without a c
compiler. I think it's a prereq. maybe something appropriate for the
yaml file, that CPAN/PLUS, Build.PL or Makefile.PL will catch.
the yaml file is generated by Makefile.PL or Build, not h2xs, from
parameters to the generating function.
I'm of the opinion a cc prereq should be in the yaml generated by
Makefile.PL or Build.PL, and therefore should be part of Module::Build
or ExtUtils::MakeMaker. CPAN/PLUS should look in the yaml for info put
there by Module::Build or ExtUtils::MakeMaker.
I don't think h2xs or other such low level parts of perl core should be
doing this.
I don't think I should put anything into Compress::Bzip2 to handle this,
although it is easy enough to do. What I would do is check for
$Config{cc}, and die pronto if it's not set. How big an issue is this?
Sorry, I wasn't a part of the original thread.
-rob
Randy Kobes wrote:
On Thu, 16 Jun 2005, imacat wrote:
I have forwarded this whole thread to Rob Janes, the current
maintainer of CPANPLUS.
Sorry first. Compress::Bzip2 won't generate reports
when $Config{"cc"} is missing. So I assume there is some
way to disable reports for missing $Config{"cc"}, and as a
XS module author you should employ that. I was wrong.
Digging into CPANPLUS I cannot found any mechanism for
that. Maybe I was wrong here again.
Personally I think whether $Config{"cc"} is available
for XS modules should be checked at CPANPLUS, and a N/A
report should be sent if $Config{"cc"} is not available.
As a module author you can check if $Config{"cc"} is
available and make some decision (although I don't know
what decision). Maybe some graceful failure on that?
And Randy, I don't agree with you. Perl may be
distributed as binaries (and that is mostly the case).
Often the building environment is not the same as the
running environment. For the OS characteristics like
$Config{"flock"}, it's reasonable to assume that it is
reliable. But for $Config{"cc"}, assuming its existence
is no doubt a mistake.
It seems to me that this issue should be decided at the
level of the Perl core, since this is responsible for
writing the glue for XS-based modules. If it was decided
that certain %Config entries should not be trusted, then it
would be more efficient to handle this at the core level,
rather than having every module author put in the same
checks.
