Re: Perl's Win32::API on MSYS
On Thu, Oct 3, 2013 at 2:23 PM, bulk 88 wrote: >> MSYS Perl currently ships with MakeMaker 6.30, GCC 3.4.4 and Perl 5.8.8. >> > Are you sure your MSYS Perl includes the file MM_Win32.pm on disk? Is your > MSYS Perl the > Perl bundled with current official MSYS git packages? Yes I'm sure, it's in the ExtUtils directory. You can actually browse my MSYS installation online at our CI server at: http://mingwgitdevenv.cloudapp.net/job/mingwGitDevEnv-test/ws/mingwGitDevEnv/lib/perl5/5.8/ExtUtils/ And yes, the Perl I'm using is the officially bundled Perl. > Also, AFAIK, if a method isn't implemented in MM_Win32.pm, it falls back to > MM_Unix.pm. A > Win32 MakeMaker makefile is made from a mix of methods from different .pms. > MM_Unix implements > cflags method, so shouldn't that be getting called instead of the Win32 > specific cflags method if > Win32 specific cflags method doesn't exist? I'm really not good at Perl at all, so maybe that's something you could check in the source code of http://mingwgitdevenv.cloudapp.net/job/mingwGitDevEnv-test/ws/mingwGitDevEnv/lib/perl5/5.8/ExtUtils/MM_Win32.pm/*view*/ Anyway, the fact that the method is not found indicates that there's no fallback to MM_Unix.pm. -- Sebastian Schuberth
Re: Perl's Win32::API on MSYS
On Fri, Oct 4, 2013 at 8:28 AM, bulk 88 wrote: > tested cosimo head "SHA-1: c5f9fcc6df4ba00c65392576eaf0e66965ff9ece * Merge > pull request #9 from sschuberth/master > Add support for building on MSYS in addition to Cygwin" + some local changes > of mine, it didn't build on my 5.6 > with MakeMaker 6.17 due to this makefile target which syntaxed errored with > nmake. Correcting the "\" to be on the right > line made it compile/work (I need to work on MY::distdir). The methods are > working on my Perl. Which version of my pull request did you actually test? Did you merge / cherry-pick commit f9fb2c5 [1], including or excluding 7fa2bb5 [2]? [1] https://github.com/sschuberth/perl5-win32-api/commit/f9fb2c599e5d9ae244be8fb4e971d57a13c0d38d [2] https://github.com/sschuberth/perl5-win32-api/commit/7fa2bb5cce9d5ce15f23ef1c5f451d066c287f8a -- Sebastian Schuberth
Re: Perl's Win32::API on MSYS
On 10/04/2013 03:11 PM, Sebastian Schuberth wrote:
Anyway, the fact that the method is not found indicates that there's
no fallback to MM_Unix.pm.
no, there is (or there *should* be, at least). this line:
@ISA = qw( ExtUtils::MM_Any ExtUtils::MM_Unix );
tells that ExtUtils::MM_Win32 is a subclass of ExtUtils::MM_Unix (and
_Any as well), so it should happily inherit methods from there.
if you execute:
perl -MExtUtils::MM_Win32 -e 'print "YES THERE IS" if
ExtUtils::MM_Win32->can("cflags");'
you should get "YES THERE IS".
I can only guess that the "package ExtUtils::MM_Win32" inside the
MY::cflags sub confuses perl 5.8.8's notion of inheritance somehow...
@bulk88: why is that line needed in first place?
cheers,
Aldo
cheers,
Aldo
RE: Perl's Win32::API on MSYS
> Date: Fri, 4 Oct 2013 15:23:36 +0200 > Subject: Re: Perl's Win32::API on MSYS > From: sschube...@gmail.com > To: bul...@hotmail.com > CC: cos...@cpan.org; libwin32@perl.org > > Which version of my pull request did you actually test? Did you merge > / cherry-pick commit f9fb2c5 [1], including or excluding 7fa2bb5 [2]? > > [1] > https://github.com/sschuberth/perl5-win32-api/commit/f9fb2c599e5d9ae244be8fb4e971d57a13c0d38d > [2] > https://github.com/sschuberth/perl5-win32-api/commit/7fa2bb5cce9d5ce15f23ef1c5f451d066c287f8a > > -- > Sebastian Schuberth Neither, I tested Cosimo master branch which has bae930423e8951107aa50453cb47b800312da18a "Add support for building on MSYS in addition to Cygwin" in its history.
RE: Perl's Win32::API on MSYS
> Date: Fri, 4 Oct 2013 15:59:30 +0200 > From: d...@perl.it > To: libwin32@perl.org > Subject: Re: Perl's Win32::API on MSYS > > > I can only guess that the "package ExtUtils::MM_Win32" inside the > MY::cflags sub confuses perl 5.8.8's notion of inheritance somehow... > > @bulk88: why is that line needed in first place? > > So SUPER class works. My code has to get the original makefile chunk MM would have put there and then manipulate it. But I tried to not be dependent on MM's design so I didn't want to call an absolute named method/sub so I switch packages in the sub and did a SUPER call. The MY package doesn't inherit anything and I didn't think about adding anything to it since MM cleans out the MY package after each WriteMakefile call which sounds unfriendly but it does that.
