Front page | perl.perl5.porters |
Postings from May 2012
On Thu May 03 20:22:11 2012, sprout wrote: > On Wed Apr 25 11:30:29 2012, rurban@cpanel.net wrote: > > > > This is a bug report for perl from rurban@cpanel.net, > > generated with the help of perlbug 1.39 running under perl 5.15.9. > > > > From a5ad7f26363aa02510e89471d9fc277dacafc259 Mon Sep 17 00:00:00 2001 > > From: Reini Urban <rurban@x-ray.at> > > Date: Wed, 25 Apr 2012 13:21:20 -0500 > > Subject: [PATCH] Win32 MSVC perlglob expansion in Encode > > > > Win32 needs to expand glob via perlglob. But this needs perl.exe, not > > miniperl.exe > > If, by perlglob, you mean the perlglob.exe built from win32/perlglob.c, > then your sentence seems to say the opposite of what I know to be the case. > > miniperl’s glob operator uses perlglob. The Win32 Makefiles are > supposed to make sure that perlglob is in the path before running > miniperl. Is that perhaps not the case? > > The full perl doesn’t use perlglob. By forcing the use of perl.exe, you > are actually bypassing perlglob and using File::Glob, for the glob operator. > > By using FULLPERL in Encode’s Makefiles, I think (without testing it) > that you are breaking the build on Unix, where Encode (like other XS > extensions) is built before perl. I don’t know what order the build > happens on Windows. > The Windows build makes miniperl.exe first, then perlglob.exe, then pure-Perl modules, then perl.exe, then XS extensions. My (almost nightly) VC10 smoker builds everything fine and most definitely does not have perl.exe (or miniperl.exe or perlglob.exe) in its PATH to start with. I recently also ran one smoke each with VC6 through VC9, and they all built fine as well. Can we see an example of the output from whatever build failure is being encountered? --- via perlbug: queue: perl5 status: open https://rt.perl.org:443/rt3/Ticket/Display.html?id=112612