Hi all, I've asked the benevolent powers-that-be at perl.org to add Eric Wilhelm as a committer to the Module-Build project. Eric has great ideas for how we can improve M::B and has backed himself up with code contributions. Welcome, Eric! -Ken
Julian Mehnle wrote: > I am getting reports of a strage error message when trying to build a > M::B 0.26 based distro (Mail::SPF, currently 2.000_003) on certain > systems that have a _higher_ version of M::B: > > http://cpantesters.perl.org/show/Mail-SPF.html > > [...] > The 'Global symbol "$VAR1" requires explicit package name' message is > the recurring pattern. > [...] > A user of my package found out that the problem could be avoided by > changing _build/build_params to say '$main::VAR1' instead of '$VAR1'. > Again, I couldn't reproduce it myself. > > Might this be a bug with M::B 0.26 based packages when they are built > with some higher version of M::B? So, does anyone have an idea what should be done about this issue? Or, more precisely, is there some work-around that I can apply in the "Build.PL" files that I distribute with my modules? I'd be glad for any help. Julian.
On Dec 3, 2006, at 3:42 PM, Julian Mehnle wrote: > > So, does anyone have an idea what should be done about this issue? > Or, > more precisely, is there some work-around that I can apply in the > "Build.PL" files that I distribute with my modules? As far as I can guess, Eric's theory is the most probable: the user started building this package, stopped and waited a few months, upgraded M::B in the meantime, and went back to the build. Or perhaps he's got a strange version of Data::Dumper? -Ken
Ken Williams wrote: > On Dec 3, 2006, at 3:42 PM, Julian Mehnle wrote: > > So, does anyone have an idea what should be done about this issue? > > Or, more precisely, is there some work-around that I can apply in the > > "Build.PL" files that I distribute with my modules? > > As far as I can guess, Eric's theory is the most probable: the user > started building this package, stopped and waited a few months, > upgraded M::B in the meantime, and went back to the build. That's extremely unlikely given that the error message occurred multiple times with the CPAN automatic testing service, and at least once with a user manually building said package of mine only one day after I had released it. > Or perhaps he's got a strange version of Data::Dumper? Is it likely that this occurs with CPANTS in the first place? Unfortuna- tely, CPANTS doesn't tell the Data::Dumper version it is using...Julian.
Adam Kennedy wrote: > Could this have happened if it he ran perl Build.PL, it went to a > dependency via the CPAN client, and then down a sub-dep which upgraded > M::B, and then it came back up and continued? I don't think so. FYI, these were the failed CPANTS builds: http://www.nntp.perl.org/group/perl.cpan.testers/369652 http://www.nntp.perl.org/group/perl.cpan.testers/374882 http://www.nntp.perl.org/group/perl.cpan.testers/375268 Julian.
On Dec 4, 2006, at 12:35 PM, Julian Mehnle wrote: > Is it likely that this occurs with CPANTS in the first place? > Unfortuna- > tely, CPANTS doesn't tell the Data::Dumper version it is using...
Hi M::B devs,
I'm in the unlucky position where a user of my Mail::SPF distro is expe-
riencing a "Couldn't run Build.PL: Argument list too long" error with M::B
0.2805 on RHEL 4.4 (see the enclosed message) and I cannot help debugging
it myself because I neither have RHEL nor understand M::B well enough to
analyze the problem.
What should I or my user do?
TIA,
Julian.
---------- Forwarded Message ----------
Subject: Re: [rt.cpan.org #21922] SPF/Mech/PTR.pm blows up with certain SPF
records
Date: Friday, 15. December 2006 20:33
From: "advax <at> triumf.ca via RT" <bug-Mail-SPF <at> rt.cpan.org>
Queue: Mail-SPF
Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=21922 >
On Sat, 9 Dec 2006, Julian Mehnle via RT wrote:
> <URL: http://rt.cpan.org/Ticket/Display.html?id=21922 >
>
> Please try Mail::SPF 2.001.
We're using Scientific Linux 4.4 (equiv RHEL 4.4), a new install.
I just installed SpamAssassin, Razor and then IO::Zlib and
Mail::SPF::Query from CPAN (required by S/A), then tried
(Continue reading)
# from Julian Mehnle # on Friday 15 December 2006 02:51 pm: >I'm in the unlucky position where a user of my Mail::SPF distro is > expe- riencing a "Couldn't run Build.PL: Argument list too long" > error with M::B 0.2805 on RHEL 4.4 (see the enclosed message) and I > cannot help debugging it myself because I neither have RHEL nor > understand M::B well enough to analyze the problem. I don't think we have yet solved this. IIRC, the current state is that we don't have a workaround which will also allow the test suite to pass. http://beta.nntp.perl.org/group/perl.module.build/2006/08/msg290.html It seems that nobody with a rhel box is able to come up with time and/or a solution. Would anybody at redhat like to look into this? AFAICT, it is a "red hat's perl" problem, where they have added some patch which over-aggressively adds foo/5.n.n directories to <at> INC ("over-aggressively" meaning, adds 20+ 5.n.n entries for each parent even if the parent INC directory exists (e.g. '-d $_') and the 5.n.n child directory doesn't (e.g. '! -d "$_/5.0.1"').) A possible user-end workaround is to manually install Module::Build and then ensure that your CPAN uses Build.PL and not the compatibility Makefile.PL. IIRC, that will work (or at least, won't "fail miserably"(TM).) A possible coded workaround would be to store our <at> INC in a wee module(Continue reading)
On Dec 15, 2006, at 5:29 PM, Eric Wilhelm wrote: > # from Julian Mehnle > # on Friday 15 December 2006 02:51 pm: > >> I'm in the unlucky position where a user of my Mail::SPF distro is >> expe- riencing a "Couldn't run Build.PL: Argument list too long" >> error with M::B 0.2805 on RHEL 4.4 (see the enclosed message) and I >> cannot help debugging it myself because I neither have RHEL nor >> understand M::B well enough to analyze the problem. > > I don't think we have yet solved this. IIRC, the current state is > that > we don't have a workaround which will also allow the test suite to > pass. I think all the tests do pass now, actually. Not that we have the ideal solution, though. What we do now is filter out non-existent <at> INC entries, and in the given test (in t/ext.t) we explicitly create the directory we're adding to <at> INC so it won't be filtered out. -Ken
Hi,
The uploaded file
Module-Build-0.2806.tar.gz
has entered CPAN as
file: $CPAN/authors/id/K/KW/KWILLIAMS/Module-Build-0.2806.tar.gz
size: 189963 bytes
md5: 919a54ab295329ab668fae14756ae80a
Changes since 0.2805:
Revision history for Perl extension Module::Build.
0.2806 - Fri Dec 15 22:20:14 2006
- On some systems (haven't identified the actual problem yet)
$ENV{PERL5LIB} can grow to enormous enough sizes that we can't
launch any more subprocesses because the environment table is full.
This is the now-infamous "Couldn't run Build.PL: Argument list too
long" error. Now we detect such situations and trim the directory
list to only include directories that actually exist, listed only
once each. Not the ideal solution, but it should work.
- Silence a warning in M::B::ModuleInfo that happens when the author
is using the "$VERSION = eval $VERSION" idiom.
- When running the 'testcover' action, do "cover --delete" if any of
(Continue reading)
RSS Feed11 | |
|---|---|
26 | |
3 | |
7 | |
3 | |
1 | |
17 | |
3 | |
4 | |
10 | |
7 | |
3 | |
15 | |
20 | |
9 | |
4 | |
3 | |
5 | |
16 | |
9 | |
21 | |
15 | |
54 | |
9 | |
23 | |
40 | |
13 | |
114 | |
51 | |
81 | |
63 | |
28 | |
146 | |
62 | |
74 | |
148 | |
45 | |
18 | |
39 | |
199 | |
22 | |
90 | |
19 | |
31 | |
2 | |
49 | |
70 | |
35 | |
39 | |
98 | |
85 | |
44 | |
39 | |
107 | |
21 | |
59 | |
67 | |
65 | |
30 | |
40 | |
14 | |
16 | |
82 | |
36 | |
100 | |
134 | |
89 | |
98 | |
203 | |
231 | |
330 | |
130 | |
60 | |
116 | |
118 | |
93 | |
47 | |
146 | |
120 | |
46 | |
113 | |
83 | |
98 | |
126 | |
205 | |
272 | |
80 | |
78 | |
45 | |
55 | |
68 | |
62 | |
121 | |
65 | |
156 | |
159 | |
111 | |
101 | |
118 | |
39 |
