All the Perl that's Practical to Extract and Report
use Perl Log In
Eric Wilhelm (6389)
Journal of Eric Wilhelm (6389)
Tuesday July 17, 2007
02:29 AM
No 'Makefile.PL' found - attempting to generate one
I do really appreciate the efforts of the cpan-testers, but some of the bare-metal smoke testing seems somewhat misdirected, especially regarding the handling of Module::Build distributions. Here's just one instance.
http://cpantesters.perl.org/show/Module-Finder.html
Every single Fail report on v0.1.4 is due to "No 'Makefile.PL' found - attempting to generate one".
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.)
So, v0.1.5 is going to include an "educational" Makefile.PL which starts with die. I know I can't educate everyone (or so they tell me), but at least I can make doing the wrong thing hurt.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
--Felix Lee
Madness.
--Larry Wall
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
Actually... (Score:1)
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 CPANThat should be NA, right? (Score:1)
When CPANPLUS says:
and then
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:
Re: (Score:1)
Isn't that more courtesy towards the user than some old ritual one has to follow? I'm constantly amazed by such ideas as Module::Build::Convert [cpan.org], which tries to automate a process for which there is absolutely no need - if it works with a Makefile.PL why move to Build.PL at all.
Courtesy vs Modernization (Score:1)
Re: (Score:1)
That depends on whether you consider EU::MM fundamentally broken or not.
Re: (Score:2)
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 be
CPAN Testers won't be hurt (Score:2)
It's your own fault (Score:1)
When you choose your build system, as when you choose ANY dependency, you get its errors and baggage along with its good points.
Module::Build has an unresolved circular dependency on itself.
Unlike EVERY other module on CPAN, it says that the rules do not apply to it and that instead of working within the rules, EVERY end user should magically (via the "universal education" clause) know to install it BEFORE they start installing anything else.
This mea
we learn from pain, we learn from history... (Score:1)
"Module::Build has an unresolved circular dependency on itself." isn't quite correct. Distributions that require Module::Build need Module::Build, but Module::Build will build just fine without anything but it's own tree.
Yes, that is a problem if the CPAN(PLUS) client can't know that it is fatally out-of-date. Everything is a problem if we have to expect an old tool (which could be easily updated) to do the right thing.
Requiring a particular *version* of M::B does need configure_requires. But the co
Re: (Score:1)
Still, I await the day when we apply the final fix.
There is another alternative to the problem/solution you suggest in that post. For every existing module pointed-to by those indices, set the URL (and checksums) of the distribution release to the location of a distribution release that upgrades the toolchain. Yes, there would be an uproar if preparations were not made by user education via public announcements and a months-ish waiting period, but it would achieve the desired effect. Mandatory upgrade ("if you're using old versions of our tools, so sorr
Re:It’s your own fault (Score:1)
“Now unrepairable”?! Yeah right! It was never a problem before, which is why CPAN::MakeMaker was never invented. Pffft.
The CPAN toolchain has always had this problem. Module::Build just put the tweezers on tight enough to force a fix.
Go on, shoot the messenger as much as you want. Won’t change anything about the reality of his message, but hey…
Re: (Score:1)
... provided that, and I paraphrase your message elsewhere, "EVERY end user should magically (via the "universal education" clause) know to install [a working make utility] BEFORE they start installing anything else."