...despite this being in the metaspec since v1.2.

It may be that all we need to do is update the regexp on line 1250. It would also be fantastic if we can just use CPAN::Meta::Validator::exversion rather than copying a regex.

@shadowcat-mst brought up that fixin be changed to accommodate relocatable perls.

His suggestion that '#!/usr/bin/env perl' be allowed is less than ideal. Programs installed with MakeMaker typically are associated with a module, possibly a particular version of a module. There's a good chance that "whatever perl comes first in your PATH" isn't going to be the right one. Alternatively, it requires careful management of what your current Perl is.

Matt, why don't you explain the problem some more please and let's see if we can figure out something?

Currently, manpages are always generated in a single action: manifypods. This means not only that pod2man has to redo some of make's file-changed checking, but also that the manification can not be parallellized.

I can imagine the current behavior being favorable on Windows (because starting new processes is rather expensive there, but for Unix this is rather unhelpful.

I've been going through the RT queue and closed some that had been already fixed and applied some patches and fixes that seemed like low hanging fruit.

I'll be whittling at them each evening for the next week or so, but if anybody else wants to have a go as well, it would be much appreciated.

Which brings me to why we are maintaining what appears to be two bug queues. I propose that we direct the bugtracker in META.* to here (i.e. Github issues) instead.

A handful of modules declare a prereq of "" instead of the traditional 0. CPAN::Meta doesn't like this and it blows up.
http://www.cpantesters.org/cpan/report/702ee2ff-6c74-1014-889e-b04980abc4c5

As it's trivial to fix, and it's very likely to occur in old modules that are unlikely to upgrade, MakeMaker should massage the versions in PREREQ_PM from empty string to 0 to make CPAN::Meta happy.

6.63_03 is testing all green with a decent mix of operating systems. 6.63_02 was also very good. Unless someone has an issue they think can't wait until the next stable, I'm inclined to call this a successful release candidate and release it as 6.64.

Let's give it a week to make sure.

Please say if you think we're ready to release as stable, or if you think there's an outstanding issue that can't wait (with issue number).

Is there some reason that the rules for C or C++ compilation don't use the -o option to specify the output file? It is sort of annoying that the object files are always put into the current directory rather than into the same directory as the C files themselves.

E.g. in MM_Unix.pm,

.c\$(OBJ_EXT):
    $command $flags \$*.c

could be

.c\$(OBJ_EXT):
    $command $flags -o \$*.o \$*.c

and then the object files would go into the same directory as the C files.

(Somewhat related to #37 and #38?)

Is there any reason that ExtUtils::MakeMaker fixin() rewrites #!/usr/bin/perl or #!perl but NOT #!/usr/bin/env perl?

1. There are many reasons #!/usr/bin/env perl do not work when installed. Keeping that line in the shebang sounds wrong to me.

2. Yet, having #!/usr/bin/env perl is useful for scripts that you want to run from a git repository etc. Look what I do with cpanm bin scripts so that you can run from a git repo by cp, but also installable to the right perl path, by rewriting the shebang in Makefile.PL: https://github.com/miyagawa/cpanminus/blob/devel/Makefile.PL#L9

There might be a valid use case for allowing #!/usr/bin/env perl as stated in #38 - so it might make sense to "allow" it by leaving as is if @INC is configured as relocatable, but by default, it makes more sense to rewrite it upon install, the same way it does with #!perl.

6.65_01 went off without a hitch, good job @demerphq! You get first crack at releasing the next stable. Follow the procedure for a stable release and as you're the first person who's not me to follow it, be sure to leave feedback and fix it up as you go.

I've already started the 6.66 milestone and assigned an issue I noticed to it.

@demerphq, if you don't want to tackle this release you can pass it on to the next person in the queue. @noirin, @shadowcat-mst and @rjbs raised their hands.

https://gist.github.com/897910

No idea how this could happen, but it occurs on perl 5.12 and 5.10.

Another example- http://www.cpantesters.org/cpan/report/fb27a132-6ce6-1014-a833-e04ea9f09604

https://rt.cpan.org/Ticket/Display.html?id=63848 makes me very nervous.

Module::Install ships a copy of itself, and ignores the locally installed version. If MakeMaker breaks Module::Install it is not enough to fix MI and release a new version. Every distribution using MI is potentially affected and potentially has to cut a new release. This is the time bomb Module::Install has brought to CPAN.

The question is, does the breakage in 63848 affect just authoring a MI-based module, or does it break installing a MI-based module.? If it's the former, we're ok. If it's the later, MakeMaker has to be changed to suit existing Module::Install releases.

This is blocking a stable release.

6.67_01
Doc Fixes
* Change references to makemaker.org in the docs
(Reported as RT#83246 by dolmen)

VOS Fixes
* 'core' files are keep files (*.kp) on vos, adjust the
  'clean' target to account for this (Paul Green)

Win32 Fixes
* Increase dmake MAXLINELENGTH to 800000 (RT#77215) as
  per kmx's recommendations (kmx)

Cygwin Fixes
* Allow linking of Cygwin libraries (Reini Urban)

I think i broke this one, will need to look into it:

http://www.cpantesters.org/cpan/report/97bf08a5-6d68-1014-84a1-ac45a9f09604

Compare with:

http://www.cpantesters.org/cpan/report/26a64d21-7e1e-1014-8102-f4142553c65e

After 6.58 is out I'd like to discuss dropping 5.6 support. 5.6.1 (the one everyone uses) is now ten years old and 5.8.1 (the first really usable 5.8) is over seven. Everyone's had all the time they need to upgrade.

I'd like to use this to build up all the things it will be easier to do without 5.6. This is particularly poignant with regard to module dependencies, 5.8 introduced a lot and we've bundled a lot of basic deps just to deal with CPAN::Meta.

I've chosen 5.8.1 because 5.8.0 was just a bit too buggy to contemplate long term support.

If somebody really wants 5.6 support they can contact us about sponsoring the work.

This might be an actual regression:

http://www.cpantesters.org/cpan/report/85100793-6d29-1014-b99b-684ba9f09604

On line 153 of ExtUtils::Mksymlists.pm, there is a dereference of $data->{IMPORTS}:

if (%{$data->{IMPORTS}}) {

This causes an error if $data->{IMPORTS} is not defined:

Can't use an undefined value as a HASH reference at C:/strawberry/perl/lib/ExtUtils/Mksymlists.pm line 153.

I am not sure whether or not this must be defined in order to compile properly. If not, I would suggest altering it to

if ($data->{IMPORTS} && %{$data->{IMPORTS}}) {

Similarly for the other use of this function.

See http://www.cpantesters.org/cpan/report/65cc664c-de8e-101d-9f23-4d053bf2bdb2 for an example. It effects ActivePerl 5.10, 5.12 and 5.14. It does not affect Strawberry Perl.

This is something to do with the code that detects nmake. Possibly they've mangled $Config{make}. I'm downloading a copy of ActivePerl to check.

We bundle version.pm, might as well use it.

• Our various $VERSION
• $VERSION comparison

Might clear up https://rt.cpan.org/Ticket/Display.html?id=78943

Two tests for 6.72 fail under ActivePerl 5.8.9 (have not tested on more recent distro):

t/min_perl_version.t ...... Set up gcc environment - 3.4.5 (mingw-vista special r3)
t/min_perl_version.t ...... 6/32
#   Failed test '  and talking like we expect'
#   at t/min_perl_version.t line 115.
# Set up gcc environment - 3.4.5 (mingw-vista special r3)
# $PREREQ_PM = {
#                'strict' => 0
#              };
# $MIN_PERL_VERSION = '5.005';
# $BUILD_REQUIRES = {};

#   Failed test 'dump has prereqs and perl version'
#   at t/min_perl_version.t line 139.
#                   'Set up gcc environment - 3.4.5 (mingw-vista special r3)
# perl(perl)>=5.005  perl(strict)>=0
# '
#     doesn't match '(?x-ism:^perl\(perl\) \s* >= 5\.005 \s+ perl\(strict\) \s* >= \s* 0 \s*$)'
t/min_perl_version.t ...... 27/32 # Looks like you failed 2 tests of 32.
t/min_perl_version.t ...... Dubious, test returned 2 (wstat 512, 0x200)
Failed 2/32 subtests
        (less 3 skipped subtests: 27 okay)

and also in...

t/prereq_print.t .......... Set up gcc environment - 3.4.5 (mingw-vista special r3)
t/prereq_print.t .......... 3/11 Unquoted string "mingw" may clash with future reserved word at (eval 9) line 1.
Scalar found where operator expected at (eval 9) line 2, near ")
$PREREQ_PM"
        (Missing operator before $PREREQ_PM?)

#   Failed test 'prereqs dumped'
#   at t/prereq_print.t line 53.
#     Structures begin differing at:
#          $got = undef
#     $expected = HASH(0x35e57b0)

#   Failed test '  without error'
#   at t/prereq_print.t line 54.
#          got: 'syntax error at (eval 9) line 1, near "3.4.5 ("
# '
#     expected: ''

#   Failed test 'prereqs dumped'
#   at t/prereq_print.t line 61.
#                   'Set up gcc environment - 3.4.5 (mingw-vista special r3)
# perl(strict)>=0
# '
#     doesn't match '(?x-ism:^perl\(strict\) \s* >= \s* 0 \s*$)'
# Looks like you failed 3 tests of 11.
t/prereq_print.t .......... Dubious, test returned 3 (wstat 768, 0x300)
Failed 3/11 subtests

If you set the environment variable ACTIVEPERL_CONFIG_SILENT=1, all tests pass.

t/min_perl_version.t ...... ok
...
t/prereq_print.t .......... ok

No patch as of yet, perhaps I will have some tuits later.

basically, if I use a decimal version and the upstream is a multipart it doesn't convert it properly for comparison.

perl Makefile.PL
Warning: prerequisite Business::CyberSource 0.004000 not found. We have v0.4.0.
Writing Makefile for MyLib::3rdParty::CyberSource
Writing MYMETA.yml and MYMETA.json

Business::CyberSource uses

 our $VERSION = 'v0.4.0';

which is a valid vstring, and passes version::is_strict tests. I can look into writing tests and a patch later.

This EUMM apparently ships with a pureperl version of Scalar::Util 1.23, which is installed if a lower version is detected. The issue here is that this version does not provide dualvar(), which is a requirement for Compress::Zlib to be able to load.

As such, installing this EUMM on older systems breaks Compress::Zlib, which in turn breaks CPAN and other things relying on it.

I am not sure what the right way to proceed here is.

http://www.cpantesters.org/cpan/report/2daf520f-6ce1-1014-83b6-fa4cef3fac6f

I was able to reproduce this on a clean system without the smoker, although i must admit i'm not sure if it's an EUMM issue, since MI seems involved.

(It's fine on 5.10.1 though.)

This one looks like it may be an actual regression:

http://www.cpantesters.org/cpan/report/aa2e7ef2-6d44-1014-860e-9854a9f09604

This one looks like it might be an actual regression.

http://www.cpantesters.org/cpan/report/d6fac99b-6d4e-1014-a7f3-d458a9f09604

Listing all the RT issues which seem to relate to spaces in the perl path:

15411 MakeMaker cannot handle spaces in perl path
49418 [PATCH] Handling spaces in path to perl install dir
69669 [patch] minimal patch for win paths with spaces
28991 [Fwd: Re: [patch] First batch of whitespace patches (ExtUtils::MakeMaker)]
448 MakeMaker busted when perl is in C:\Program Files

Hi. I would like to roll an alpha release.

If I understand the docs correctly it would be 65_01.

Thanks,
Yves

These exhibit odd behavior:

http://www.cpantesters.org/cpan/report/e57bbe7f-6de5-1014-a403-a0203373d4b5

http://www.cpantesters.org/cpan/report/ddad2e66-6de3-1014-997d-281c3373d4b5

See https://rt.cpan.org/Ticket/Display.html?id=67295

CPAN::Meta will choke if given a version object. That's no good. MakeMaker by accident stringifies VERSION_FROM but not necessarily versions in provides or user supplied versions.

There's a patch in Perl-Toolchain-Gang/CPAN-Meta#4

MakeMaker must be able to generate a META file without an optional CPAN::Meta dependency. It doesn't have to be perfect, it just has to be there. Otherwise most authors will not even notice it's missing and CPAN will lose a large chunk of it's metadata.

A solution appears to be to put CPAN::Meta, and it's few dependencies, into inc and install the if it's not installed or out of date. This is the same system used by ExtUtils::Install and the rest and it works well.

This blocks a stable release.

When there are unicode characters in the Makefile.PL I get the following warning:

Wide character in print at /home/gabor/perl5/lib/perl5/ExtUtils/MakeMaker.pm line 1027.

See https://github.com/datamuc/Pastedance as an example

Track progress up to 6.70

The following code lines in EU::MM_Unix (currently starting from line 1162) look dubious to me:

    my (@absdirs)
        = reverse grep { $self->file_name_is_absolute($_) } $self->path;
    $interpreter = '';

     foreach my $dir (@absdirs) {
        if ( $self->maybe_command($cmd) ) {
            warn "Ignoring $interpreter in $file\n"
                if $Verbose && $interpreter;
            $interpreter = $self->catfile( $dir, $cmd );
        }
    }

Especially the loop over @absdir, but the variable $dir is not used in the maybe_command call. So basically the loop is always checking just for the same $cmd (maybe "$dir/$cmd" resp. File::spec->catfile($dir,$cmd) was meant?). And given that $cmd is just a base name and not a path, this is probably never and nowhere true. So the only effect of the whole else branch seems to be to set $interpreter to the empty string (previously undef).

It looks to me that these code lines could be deleted.

Regards, Slaven

ExtUtils::testlib is not used. It doesn't look like it ever was, not since the modern repository began in 2002.

Its utility is duplicated by ExtUtils::Command::MM::test_harness() which makes blib/lib and blib/arch into absolute paths.

It should probably be deleted. It's distracting, a number of time it's been patched assuming it would have an effect on how the tests are run.

My very minor concern is that someone is making use of it, so removing it would break existing code. I'm not too concerned.

It's been a year since the last alpha and the last stable. So I'd like to focus on getting something out the door.

To that end, I'm stamping what we've got as 6.63_03 and releasing it. This is also release candidate 1 for 6.64. This issue is to let folks know and also to record any alpha release blockers.

Any issues which would block stable, please put into the "Next Stable / 6.64" milestone.

Officially we currently do not support GNU make on Windows. We only support nmake (Microsoft proprietary software) and dmake (open source abandonware). I'm pretty sure perl itself currently doesn't build with gmake, given the Win32 makefile has BSD make logic in it (and gmake is SysV), but I see no reason why it wouldn't work for ExtUtils::MakeMaker (which is lowest common denominator enough that it works on any make). It would be useful to verify that, and which could ultimately mean Strawberry (and others?) could switch to a make implementations that is actually maintained.

Currently, the META.* files are generated when the Makefile is generated. This is a waste of time as it's only useful when releasing. It also means CPAN::Meta is always required (or must silently fail). See rt.cpan.org 76720 for an example.

• Move the code for generating META.* into ExtUtils::Command::MM.
• Change the metafile target to run the new ExtUtils::Command::MM target.
• Have the metafile target fail if the generation fails or CPAN::Meta does not exist or is too low a version.

While MakeMaker isn't doing anything wrong at the moment, I'll be merging a branch to blead that will add a pure-perl implementation of mod2fname if perl is configured with -Dd_libname_unique.
The downside of being pure-perl is that it'll not be available everywhere like the ones currently provided on VMS and OS2; to be entirely safe. MakeMaker will have to load DynaLoader beforehand.

So it would be great the something like the patch below could get applied.

diff --git a/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_Unix.pm b/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_Unix.pm
index a7a5e1b..ae5af1f 100644
--- a/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_Unix.pm
+++ b/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_Unix.pm
@@ -1594,6 +1594,8 @@ sub init_main {
# Some systems have restrictions on files names for DLL's etc.
# mod2fname returns appropriate file base name (typically truncated)
# It may also edit @modparts if required.

• We require DynaLoader to make sure that mod2fname is loaded

• eval { require DynaLoader };
  if (defined &DynaLoader::mod2fname) {
  $modfname = &DynaLoader::mod2fname(@modparts);
  }

I've written a quick script to compare the smoker results between those versions. The comparison itself is here and will be updated from time to time:

http://dl.dropbox.com/u/10190786/reports/comparison.html

Code for your own comparisons is here: https://gist.github.com/890253

Please, whenever you find some time, look into the dists listed at the top to see if the various non-PASSes they suddenly are generating come from the new EUMM.

Making a note here because rt is down again. Sometime in the future i need to poke at this to make sure it generates linux newlines all the time.

I did a quick scan of the code, and it appears there is little to no tests for the scenario where a user needs to depend on a 3-part version.

So, I've thrown together some tests for the 5 v-string family scenarios to see how they work out:

kentfredric/ExtUtils-MakeMaker@master...vstring-tests

'1.2.3'  # works, turns up in META_new.yml as "v1.2.3" , but warns about "Not numeric in addition"
'v1.2.3' # doesn't work, Can't parse version , emits a dependency on version 0 
v1.2.3  # doesn't work, Can't parse version,  emits a dependency on version 0
'v1.2'   # doesn't work, Can't parse version, emits a dependency on version 0
v1.2  # doesn't work, Can't parse version, emits a dependency on version 0

As all these versions are to the best of my knowledge "legal" in some capacity, it seems strange that of all of these, the only one that works is the stringified one without the v-prefix, which contradicts best practices for using 3-part versions, which states you should prefix with a v , and in many cases, it prefers it "bare" , not stringified.

So I'm hoping that EUMM can be improved to add support for half of the above notations, or at least one of the "v" prefixed forms for both 3-part dotted decimal and 2-part dotted decimal.

I think the recommended path is as follows:

'1.2.3'  # Forbidden
'v1.2.3' # Forbidden
v1.2.3  # the same as "1.002003"
'v1.2'   # Forbidden
v1.2  # the same as 1.002

However, that seems a little strict, and at least this set would be more useful:

'1.2.3'  # Forbidden - Please add a 'v' 
'v1.2.3' # the same as "1.002003"
v1.2.3  # the same as "1.002003"
'v1.2'   # the same as "1.002"
v1.2  # the same as "1.002"

Note (probably harmless): No library found for -lfoo is usually a lie. It is important and it will cause harm.

I propose removing the "Note (probably harmless): " bit.

A little history traces this back to fb73857a in the Perl repository back in 1997 where "continuing anyway" was changed to "probably harmless" when this code was more closely wielded to the Perl build process. The full rationale was:

If you see such a message during the building of an extension, but
the extension passes its tests anyway (see L<"make test"> below),
then don't worry about the warning message.  The extension
Makefile.PL goes looking for various libraries needed on various
systems; few systems will need all the possible libries listed.
For example, a system may have -lcposix or -lposix, but it's
unlikely to have both, so most users will see warnings for the one
they don't have.  The message 'will try anyway' is intended to
reassure you that the process is continuing.

This is certainly not true for most CPAN modules.

Test::WWW::Selenium seems to trip up on the new CPAN::Meta:

https://gist.github.com/898054

MakeMaker predates this distinction, and is currently ignoring it entirely. The consequence is that it spews various warnings when any argument contains characters >255, as in Acme::LookOfDisapproval. It's pretty much assuming octets, which I'd say is not the most sensible thing to do…

Related to this: what is the encoding of the Makefile? Currently it's rather undefined, and the end-result can be either latin-1 or utf8. It should probably be utf8, because the current behavior generates mojibake metafiles for high-latin-1 input (such as any MYMETA file for @dolmen).

On Win32 systems it can happen that .a and .lib names for library files are mixed, since it is possible to install distributions compiled with visual studio alongside dists compiled with gcc.

This broke modules like true.pm ( https://rt.cpan.org/Ticket/Display.html?id=65586 ).

To fix this i went in and refactored the entire _win32_ext subroutine today. The changes are in this branch: https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/tree/win32_liblist_kid

(I would've branched at a more current commit, but everything past 0348 seems to have broken tests on windows.) Just fixed this and the branch is off the most recent master commit.

Before i merge this back to master i'd like to have at least one other person review the changes to see if i made any oversights.

Similarly, i couldn't find any detailed tests of Liblist behavior. Should i create detailed tests to make sure this new behavior keeps working on Win32 or would the existing tests be enough for that?

MakeMaker 6.58 will break Module::Install's tests. The MI folks know this and have asked we hold off until after the QA Hackathon this weekend when they'll make a release.
https://rt.cpan.org/Public/Bug/Display.html?id=61464#txn-917526

Wanting to cut an alpha release, thanks!

The CPAN meta spec 1.4 and 2.x are incompatible. META_ADD and META_MERGE take 1.4 style meta information and convert it to 2.x (or whatever we're emitting to META.blah). This should be documented.

MakeMaker changes the #! line to match the installed Perl, which is good, but it also adds in this:

#!/path/to/bin/perl

eval 'exec /path/to/bin/perl -w -S $0 ${1+"$@"}'
    if 0; # not running under some shell

This exists to fix systems which do not honor the #! line and instead execute the file with the shell. Really, really old and really, really broken Unixes. I doubt modern MakeMaker still works on them, so I'm happy to see this historical oddity removed. One less bizarre thing to explain.

There's a rash of Mkbootstrap.t failures in 6.64. 6.65_01 isn't well tested on Cygwin. They mostly were run by @pjacklam.

Investigate the failures, see if 6.65_01 fixed them.

META_ADD and META_MERGE take v1.4 style meta info by default (see #30). Add the ability to specify what major meta version is being used.

# implied v1.4
META_ADD => {
    blah => { blah => "blah" }
};

# explicit v1.4
META_ADD => { 'v1.4' => {
    blah => { blah => 'blah' }
}};

# explicit v2
META_ADD => { 'v2' => {
    blah => { blah => 'blah' }
}};