Hi Matt, On Sun, Jul 25, 2010 at 9:04 PM, Matthew Kenworthy <[email protected]> wrote: > 1) With the combination of OSes and processors, we would end up > supporting approximately a dozen or so static builds, each probably 1 > Gb in size, as we have to build a perl from scratch for each > combination. I know this because I did this for Mac OSX as an > experiment prior to building SciKarl in January 2010.
Wow. How come this isn't a problem for Padre? They have only one static download for Windows, one for Linux, one for Mac. For other OS's or other CPUs you use CPAN. > 2) More fundamentally, PDL is built on Perl, and people expect PDL to > work with Perl modules they've installed themselves. WIth a static > build, there would be two perls on a given system, leading to lots of > Module confusion (I've tied myself in knots with this problem....) I'm not thinking of current Perl users, I'm thinking of Matlab users who are not Perl users. Ultimately I want to be able to tell a colleague that there is a free Matlab alternative that they can try out. But I will only do that if that alternative is reliable, easy to install (for a non-Perl user), and properly documented. A PDL that only serves existing Perl users is not a PDL I would recommend to colleagues. > We also have PDL dependent on libraries that are beyond our control, > such as fortran for PGPLOT, and I've always hit stumbling blocks with > PLplot not correctly building, and then people (incorrectly) blame PDL > for these problems. This is a slight tangent, but I actually side with those people. If you choose to base your software on an unreliable platform, you are responsible for that choice. Daniel. -- Intolerant people should be shot. _______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
