On Sun, Jul 25, 2010 at 11:07 PM, Daniel Carrera <[email protected]> wrote:
> 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.
It's easy.
Only the Windows version actually works.
Even that took Curtis Jewell quite a while to build the msi package even
after Adam Kennedy spent lot of time making sure Strawberry Perl works well.
The Mac file we have is old and only works on Snow Leopard - but no one keeps
it up to date.
The Linux version works only on a limited set of distributions, even there it
is partially broken and not up to date.
So Padre has not reached installation Nirvana yet either :)
IMHO you guys could also think in a layered distribution and not
trying to solve all
the problems at once.
Let me call SciPerl a list of packages that are needed for scientific
Perl. Including
PDL and a bunch of it optional dependencies and maybe some other packages.
I'd go for something like this:
1) Make sure SciPerl can be easily installed from CPAN on Linux while
does not break
(too much) the process of the downstream distributors (Debian etc.)
2) Maker sure SciPerl is included in the major downstream distors by
asking the packagers
and helping them where needed.
3) Create stand-alone package of SciPerl for Windows 32 bit
(preferably bundled with Padre,
most preferably part of Strawberry Perl Professional or a derivative of it)
4-30) Create stand-alone packages for Windows 64 bit and other OS-es.
Padre is half way through 3) now.
I think 1) will be an improvement for most of the current users and in
general Perl developers.
2) will ensure people in more restricted environments will be able to
rely on vendor packages.
3) Probably covers the biggest number of people who are not yet perl
or PDL users,
as Daniel Carrera also wrote, the people who don't really care (at
this point) that this
is in Perl.
4..30 are the same as 3 but but for OSes that are used a lot less.
I would suggest not to try to build a generic solution from the
beginning. Try to solve each OS
one by one. Maybe you can even skip Mac OSX as SciKarl might give the
solution there.
(I have no clue, I never had a Mac).
regards
Gabor
_______________________________________________
Perldl mailing list
[email protected]
http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
