[rt.cpan.org #86609] MakeMaker Fails to Recognize v-string Versions

Recognise $VERSION = v0.10.3 type declarations when using
VERSION_FROM.
Handle v-strings when they are specified as VERSION in WriteMakefile()
Bump to v6.69_02 and update Changes
Install into 'site' if 5.12 and above

http://www.nntp.perl.org/group/perl.perl5.porters/2013/07/msg204337.html
Update Changes
Apparently stripping spaces from a v-string is a no-no
[RT #61419] Avoid invisible interactive question when rebuilding Makefile

Under certain circumstances it is possible that using "make" apparently
hangs. It can happen if:
- the project contains subdirectories with Makefile.PLs
- at some time root created a Makefile.old in a subdirectory (this may
happen easily if "sudo make install" is used but the Makefile needs to
be recreated)

To reproduce this, grab some CPAN distribution with subdirectories, for
example "Encode" and try the following command sequence:

$ perl Makefile.PL
$ touch Byte/Makefile.old
$ sudo chown root Byte/Makefile.old
$ touch Makefile.PL
$ make
Makefile out-of-date with respect to Makefile.PL
Cleaning current config before rebuilding Makefile...
make -f Makefile.old clean > /dev/null 2>&1

At this point it hangs. To see what happens just remove the redirect to
/dev/null:

$ make DEV_NULL=
...
mv Makefile Makefile.old
mv: overwrite `Makefile.old', overriding mode 0644?

The attached patch seems to fix the problem. Note that alternatively
$(MAKEFILE_OLD) could be pushed into the @files array for removal.

Signed-off-by: Chris 'BinGOs' Williams <chris@bingosnet.co.uk>
[RT #54703] Don't hardcode /cygdrive

'make test' in blead perl is producing the following failure:

cpan/ExtUtils-MakeMaker/t/MM_Cygwin............................#
Failed test ''/c/WINDOWS/system32/cmd.exe' should be executable"'
FAILED at test 12

Since maybe_command() in MM_Cygwin.pm is hardcoded to look for
'/cygdrive', the test fails if the user changes the mount point prefix
from '/cygdrive' to something else using 'mount -c ...'.  (For example,
I use 'mount -c /'.)

The attached patch fixes this finding the mount point prefix and using
it to determine if Unix or Win32 settings should be used.

Signed-off-by: Chris 'BinGOs' Williams <chris@bingosnet.co.uk>
Bump to v6.69_03 and update Changes
Revert "[RT #54703] Don't hardcode /cygdrive"

This has been found to cause more problems that it solves.

There is a patch from Reini that pertains to resolve the same issue.

This reverts commit 22dd67bcc830fe30ab915b2ab1ef8362bbef8203.
[RT #69401] 93862c2 Stabilize ExtUtils::MM_Cygwin::maybe_command

also [perl #94532]

Be independent of /cygdrive prefixes. Failed with a prefix like "/".
Suggestion by Marco Moreno, patch by Reini Urban.

Also resolves [RT #54703] [PATCH] Don't hardcode /cygdrive

Signed-off-by: Chris 'BinGOs' Williams <chris@bingosnet.co.uk>
Update Changes and bump to v6.69_04
parse_version improve/fix tests

For samples like "$Something::VERSION == 1.0" we're testing
that parse_version returns "undef" (string).

However, I believe, we should tests that it never tries to eval() it

Before this fix samples like "$Something::VERSION == 1.0"
evaled, and result was undef. But code like:

my $x = $Something::VERSION == 1.0 ?
   "abc" : "def"

will fail if we try to eval first line.
parse_version - fix regexp and tests

fix regexp and tests for samples like $Something::VERSION == 1.0
addresses RT#9452 regression Jul Y2013
Merge pull request #62 from vsespb/master

Fix parse_version tests and improve regexp
Ignore once warnings as well
[PATCH] Make EU::MM use LD and OPTIMIZE in recursive Makefile.PL invocations

In a directory hierarchy with Makefile.PL files in subdirectories,
command line arguments like
 perl Makefile.PL OPTIMIZE="-g -O0"
are not used in the generated subdirectory Makefiles.

This seems to be by design: there's a short list of variables
that are inherited, the rest are not taken into account at all.

Debian needs LD and OPTIMIZE for sane handling of security
related build flags, so add those to the whitelist.

Bug: http://rt.cpan.org/Public/Bug/Display.html?id=28632
Bug-Debian: http://bugs.debian.org/660195
Patch-Name: debian/makemaker-recursive.diff

Signed-off-by: Chris 'BinGOs' Williams <chris@bingosnet.co.uk>
Update Changes and bump to version 6.69_05
[RT#79348] ExtUtils::MakeMaker doesn't support miniperl in installation paths

The following was originally filed in the Perl 5 bug queue as
https://rt.perl.org/rt3/Ticket/Display.html?id=80040.  As
ExtUtils-MakeMaker is primarily maintained on CPAN, I am moving that
report to this queue. -- Jim Keenan

This is a bug report for perl from perl-binary@plan9.de,
generated with the help of perlbug 1.39 running under perl 5.12.2.

-----------------------------------------------------------------
[Please describe your issue here]

ExtUtils::MM_Unix contains this line:

($self->{FULLPERL} = $self->{PERL}) =~ s/miniperl/$perl_name/i
unless $self->{FULLPERL};

This corrupts any path thatconatisn miniperl in it's name. I found out
about this beause I have prefix=/opt/miniperl and CPAN was failing
because it looked for /opt/perl/bin/perl (which confusingly also existed :).

Probably a $ at the end of miniperl would fix this while introducing a
nice $/$ triple combo, but I am no makemaker expert :)

[Please do not change anything below this line]
----------------------------------------------------------------
doc: Fix the META_MERGE example