Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine

Re^4: [JOB] The Perl Foundation seeks Windows Developer

by Steve_p (Priest)
on Apr 02, 2006 at 05:14 UTC ( #540705=note: print w/replies, xml ) Need Help??

in reply to Re^3: [JOB] The Perl Foundation seeks Windows Developer
in thread [JOB] The Perl Foundation seeks Windows Developer

Work has already been done by Gisle Aas of ActiveState to allow XS modules to be compiled with either the MinGW gcc or Visual C++, regardless of the compiler that Win32 Perl was built with (see Perl change #27555 for details). I'm pretty sure that Perl has been able to be built with either dmake or nmake with Visual C++ for some time now. It would be nice, however, and I'm sure you would agree, to allow users their choice of compilers on whatever operating system they choose. I would hate to see this project be a step backwards in Perl support on Win32.

With Windows Vista, all indications are that support for the free nmake will go away. The nmakes provided with recent Visual Studio's or .NET SDKs will still work. In exchange for losing free nmake support, however, we will have a usable and programmable shell that may be able to be used to provide a sane Configure script. So, I see Vista as a great new opportunity and challenge for porting Perl rather than an obstacle.

As far as working with commercial compilers, Perl is everywhere and should be able to be compiled with any sane C compiler, commercial or not, just as it is supported on almost every free and commercial operating systems. Whether the C compiler is commercial or not should be irrelevant. Support for Visual C++ 8.0 will be provided. Its simply a matter of time. I consider it to be a major bug that it isn't supported at this time. This is why I see this support as important for this project.

  • Comment on Re^4: [JOB] The Perl Foundation seeks Windows Developer

Replies are listed 'Best First'.
Re^5: [JOB] The Perl Foundation seeks Windows Developer
by adamk (Chaplain) on Apr 02, 2006 at 09:45 UTC
    Let me restate my previous point.

    I'm NOT saying that it isn't a good thing to support more compilers. Playing well with others is a GOOD thing.

    And most of this grant is not about adding MinGW compatibility, because almost everything works already anyway.

    This grant is firstly about fixing things in Bundle::CPAN that don't work, or have major bugs, on any Win32 platform, Vanilla or Strawberry or ActivePerl or otherwise.

    Because there's a lot of bugs for things as simple as Term::ReadLine::Perl, or that to relate to the fact doesn't play well with the Windows firewall. All the normal portability and platform-specific stuff.
    And the second part is fixes to deal with other secondary problems that have emerged because the bulk of Windows users currently don't need to use CPAN, and a few bug fixes to remove assumptions caused by CPAN authors treating ActivePerl bundled modules as if they are in the core and thus not listing those dependencies in their (Makefile|Build).PL

    That's what THIS grant is about. IT's about making all the modules in the Perl toolchain intrinsically sane on Windows.

    This doesn't invalidate the importance of adding support for newer and different compilers. But it is a mostly orthogonal task, and so it would be the subject of a different grant.

    And in the process, this grant creates an option for people to use a Perl distribution that is both simple to install, without requiring a knowledge of C, and entirely libre from the compiler on up.

    Because I for one don't write C, can't stand Visual Studio, and just want my Perl modules to install, without having to care about C compilers.

      and a few bug fixes to remove assumptions caused by CPAN authors treating ActivePerl bundled modules as if they are in the core and thus not listing those dependencies in their (Makefile|Build).PL

      IMO the much better solution is to just put those modules in Core in the first place.


        Even if certain Windows-specific modules were added to the core _today_, these fixes would still need to be done to deal with older installed Perl versions.

        Whether or not something should be in the core is an orthogonal problem to this grant, but I'll address it in my reply to one of your other comments, below.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://540705]
[hippo]: Understood. I'll have to go through the code and see if it's doing anything fancy with ties, dual-vars or non-scalars. In the end, it's probably a bug though.
[Corion]: Aaah - you should be able to do this with overload, but I would hit somebody really hard if they constructed objects that are true but the empty string, and you not knowing about the domain knowledge where this makes sense
[Eily]: you could tie a variable into not having the same value each time, if you like to make people who try to debug your code facepalm
[Corion]: perl -wle 'package o; use overload q("") => sub {warn "str"; ""}, bool => sub{warn "bool"; 1}; package main; my $o={}; bless $o => o; print "Yay" if ($o && !length($o))'
[Corion]: But people writing such code should document the objects they construct and why it makes sense for an object to be invisible as string while being true in a boolean context
[hippo]: That's equal parts clever and horrendous.
[Eily]: the overload version wouldn't return true with "$x" && !length $x though, I guess
[hippo]: The more I look at this code, the more $x is a plain old scalar and the more this condition will never be true. I'm calling it a bug at this point.

How do I use this? | Other CB clients
Other Users?
Others about the Monastery: (14)
As of 2017-07-27 13:38 GMT
Find Nodes?
    Voting Booth?
    I came, I saw, I ...

    Results (413 votes). Check out past polls.