Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

No 'Makefile.PL' found - attempting to generate one 3 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.

  • Every single Fail report on v0.1.4 is due to "No 'Makefile.PL' found - attempting to generate one".

    Actually, every fail report is due to:

    [ERROR] [Mon Jul 16 19:12:23 2007] This module requires 'Module::Build' and 'CPANPLUS::Dist::Build' to be installed, but you don't have it! Will fall back to 'CPANPLUS::Dist::MM', but might not be able to install!

    The clue is in the [ERROR] tag...

    I would prefer to *not* include Makefile.PL at all because there is another configuration scheme which says "prefer Makefile.PL over Build.PL?" (And of course it defaults to the wrong answer.)

    You will keep running into issues like these until either all machines have Module::Build support, or the config_requires: extension to META.yml is accepted, implemented and supported in all deployed versions of CPAN

    • When CPANPLUS says:

      [ERROR] [Mon Jul 16 19:12:23 2007] This module requires 'Module::Build' and 'CPANPLUS::Dist::Build' to be installed, but you don't have it! Will fall back to 'CPANPLUS::Dist::MM', but might not be able to install!

      and then

      No 'Makefile.PL' found - attempting to generate one

      it is trying to be helpful. But the smoker module (be it CPAN::YACSmoke, CPAN::Reporter or whatever) should recognize this case as NA and not FAIL. Would it be hard to tell this case apart?

      On another note, Bundle:

      • Would it be hard to tell this case apart?

        Actually yes it is. This part of the configuration is not captured well in EU::MM and M::B and as a consequence CPAN.pm and CPANPLUS have to jump through hoops to get at it. Last time I checked EU::MM handles this better.

        recognize this case as NA and not FAIL.

        NA has a specific meaning, in that the module does not work on that perl/platform. This isn't the case in this situation, so should be a FAIL as the author is not providing support for the current standard toolchain. If they choose to insist on M::B then at the moment that will break because M::B isn't part of the current standard toolchain. In 5.10 M::B will be in core, so it can then be considered part of the standard toolchain. Assuming your user base will have exactly what you have on your machine is why you get FAIL reports.

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.