Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Using CPAN Modules Across Multiple OS

posted by pudge on 2000.12.11 11:53   Printer-friendly
Jaxon writes "I need to run the same set of Perl scripts on multiple operating systems (AIX, HPUX, Linux, Mac, Solaris and Win32). I have been trying to stay within the confines of the lowest common denominator, MacPerl 5.2.0r4 (based on Perl 5.004). However, I would like to start utilizing CPAN modules. What resources are available to determine each module's compatibility and stability on across all of these platforms?"

CPAN Search gives data from CPAN Testers. CPAN Testers is not as complete as it could be, all that's missing is more volunteers (Paul Schinder can only do the work of five people, after all).

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • It'd be nifty to see a place where the CPAN Tester stuff was in order by machine type... that is, something like "Macs have issues with modules Foo::Bar, Baz::Qux, and..."

    (Of course, now I'm only using two platforms regularly, and Win32 Perls no longer have the weirdo issues like "guess which way the slashes should go THIS version," so I pretty much ignore the Testers stuff anymore, hurrah. A cross-platform language that actually works well cross-platform... who knew?)

  • http://testers.cpan.org/search?request=by-config

    Of course, the testers results are also shown with each distribution on http://search.cpan.org/

    e.

    I want a pony....
  • Can't be right. No AS/400's?

    I'm shocked. Shocked, I say.

  • I would put more time into figuring out how to hack MacPerl, but it's not really worth it since it's going to be defunct soon anyway with MacOSX.

    I was just hoping that someone had already figured it out and had posted the info somewhere.

    But for now I have to use an operating system with no forking sense and noi dea of cwd.

    The CPAN site is already turning out to be a valuable resource.

    BSD saves the Mac, who knew. ;)

    -Jaxon
  • I would put more time into figuring out how to hack MacPerl, but it's not really worth it since it's going to be defunct soon anyway with MacOSX.

    No, it won't. Some of us probably won't use Mac OS X for one or more reasons (not the least of which is that the UI sucks eggs). If the serious UI problems are not fixed, I estimate I won't switch to Mac OS X for my main OS for at least two more years, maybe longer.

    I was just hoping that someone had already figured it out and had posted the info somewhere.

  • I want to use MacPerl for autmomated builds, so I am not interested in the UI. I most likely would hardly ever see it.

    >>I was just hoping that someone had already figured it out and had posted the info somewhere.
    >
    >What info?

    Info on working with MacPerl on MacOS (like 8.5-9.x). There are alot of problems.

    > MacPerl uses cwd. Maybe not the one you want, but that is easy enough to deal with in various ways.

    MacPerl may use cwd, but Mac doesn't always know where cwd is, so the information
  • I want to use MacPerl for autmomated builds, so I am not interested in the UI. I most likely would hardly ever see it.

    I am not talking about the UI for MacPerl, I am talking about the UI for Mac OS X. It sucks, IMO, so I won't be using Mac OS X for some time. I am not the only one who feels this way. MacPerl will thrive for years to come, rest assured (or not :-).

    Info on working with MacPerl on MacOS (like 8.5-9.x). There are alot of problems.

    OK. Such as? If you want info to help you with your p

  • Thank you. Sorry to come across so vague, I just wanted the links to go start researching. With all the the links posted so far, I think I am off to a good start.

    When this is all running -knock wood-, I will not be using any GUI (MacPerl or MacOS). Since my project is Build Automation; c/c++ source will get pulled, compiled, results posted and a report generated. All under the watchfull eyes of MacPerl. This currently works for me great under various *nix platforms and Win32.

    Look Ma, NO HANDS! ;)

    Also,
  • Well, good luck. Just remember, if you need help, the MacPerl list is a great place to go. MacPerl really does have only a few significant problems, like memory limitations and lack of forking (indeed, it is difficult (though not impossible) to even have MacPerl call another instance of itself).

    Most other things, calling external apps, etc. (like you might need in build automation) is not very difficult if you plan on using MPW tools. You'll need MPW and ToolServer (free from Apple). If you want to ca