in reply to Re: Suggestions on Deploying Perl Test Environment
in thread Suggestions on Deploying Perl Test Environment

I'm not fond of windows but I'm not a zealot. I've spent about a week now trying my best to get an automation install working in windows but every time I take a step, I slam into a brick wall.

The current problem I'm facing appears to be a bug in ExtUtils/MM_Win32.pm. From another thread (http://www.perlmonks.org/?node_id=603230) I found that that module determines what the directory file separation character(s) should be. Testing it with dmake and mingw make in the path and also set in Config.pm never changes $self->make in MM_Win32.pm. Since it thinks the make tool is nmake instead of dmake og mingw make, it resorts to '^\' for a separator that doesn't work with those two make tools. I'm uncompressing the Microsoft Shared Source Common Language Infrastructure 1.0 that should have the tools in it I need according to another thread I've seen. I'm curious if it has nmake with 64bit support as well as ia64 support. If not, I'm back to square one with Windows.

As for modules that work in windows and not in linux or vice versa, that's already understood. We have a procedure in place for that. Basically we test out each module before deploying it and mark what OSes the module works in.

So the question remains, how can we build across multiple platforms in windows? Everything I see for the MS C++ compiler is 32bit only which will work for the x86_64 platforms but not for ia64 (well... it isn't ideal). Do you have experience using the Visual Studio 9.0 (free version) on the different platforms. IE does it work?

  • Comment on Re^2: Suggestions on Deploying Perl Test Environment

Replies are listed 'Best First'.
Re^3: Suggestions on Deploying Perl Test Environment
by hsmyers (Canon) on May 12, 2008 at 21:35 UTC
    VC9 paid for, not free and then only for 32bit land. Lack of adventurous customers I'm afraid. Your problem with MM_Win32.pm illustrates one of my pet peeves in perl-land. Something I refer to as 'nix bigotry. The in-ability of unix programmers to cut code for windows and get it right. Since they all know that they are the one true way, there seems to be little effort put in coding for the evil empire. I've seen this far more often in CPAN than I like. Not that my contributions amount to all that much, but I bend over backwards in getting things right for other operating systems only to see problems like yours all around. And thats for the few that even bother to make things work for the 'other' OS! Sorry about the rant, but I've been where you seem to be more than once and for no better reason than people can't be bothered to do things correctly. Have you tried the cygwin solution yet? I've gone that way once or twice but have never stuck with it long enough to take...

    --hsm

    "Never try to teach a pig to sing...it wastes your time and it annoys the pig."
[reply]
      Your problem with MM_Win32.pm illustrates one of my pet peeves in perl-land. Something I refer to as 'nix bigotry. The in-ability of unix programmers to cut code for windows and get it right.

      Hold on just a minute.

      I (and I assume plenty of other CPAN developers) would be happy to apply patches from Windows users. If Windows users paid me enough, I might even consider writing patches for them myself.

      As it is, I've never owned a computer that runs Windows, and I have no intention to do so in the same way that I've never owned a computer that runs VMS and I have no intention to do so. I write code, for free, and release code under a very free license in the hope that it is useful for other people.

      If that's not good enough for you, such that you feel the need to berate me for not doing more, you can still use the code. It's that free.

[reply]
      A reply falls below the community's threshold of quality. You may see it by logging in.
      Linux doesn't force Windows people to pay in order to work on compatibility...
[reply]

In Section Seekers of Perl Wisdom