Hi Chris,
On Sat, Jul 31, 2010 at 8:39 PM, Chris Marshall <[email protected]> wrote:
> On windows you need to use dmake rather than make
> but the rest is the same. It is equally a one-line
> process if you use the cpan shell.
Let's take the simplest source install method. We can agree that
that's "cpan", right? Even the "cpan" method does not save you from
having to write platform-specific instructions. You still have to show
users where to get a build environment with gcc, make and libc and how
to set it up. This step alone is more complicated and no less
platform-specific than the PDL binary install. So you don't save
anything. In fact, you just made it more complicated because now the
user has to setup several packages (gcc, make, libc, cpan) instead of
just one (PDL) and all that is just as platform-specific as the PDL
install you were trying to replace.
> The point for the source install was that it is
> pretty much identical for all platforms which makes
> one-stop shopping even more helpful to potential
> PDL users.
Ah, but it is only identical after you have setup the build
environment. Setting up gcc, make, libc and cpan is very much
non-identical between platforms. You have not reduced the
platform-specific instructions, you have just pushed them to a
different step and made them more complex and more fragile (more
packages to install and more packages that can go wrong).
> Have you looked a the manual install directions?
> That is pretty much how to do everything from scratch
> for building a perl + PDL development environment with
> notes on configuring all the dependencies too. As is,
> it is a bit more than just installing PDL but it is
> definitely a needed resource.
If that's the distinction you see, then you will have to change the
name because a source install is very much manual. As a user I never
would have thought of the difference that you just tried to draw
("manual" = "every feature").
> No, I saying that the "Get PDL" page should allow one
> to get PDL as directly as possible.
We agree on that goal. We disagree on which way to get PDL is more
direct. I think that:
1) yum install perl-PDL
is much more direct than:
1) Install gcc, make, libc and cpan.
2) perl -MCPAN -e shell
cpan> install PDL
Btw, "cpan PDL" does not work in every platform. I had trouble getting
that to work with some Linux distributions when I was writing the PDL
install instructions. That's why I use "perl -MCPAN -e shell", that
one seems to work more reliably.
> The binary installs are all platform based and I think
> the existing layout is ok there with easy to see and
> follow links.
The installation of a build environment including cpan is also platform based.
>> How so? The source build requires more dependencies, more knowledge
>> and more time. In which way is this "best"?
>
> The only platform that has an all-in-one package for
> PDL at the moment is Mac OS X. All the others have
> exactly the same set of dependencies as bulding from
> source would have---and the possibility that you'll
> be missing some key PDL feature because everything
> isn't quite there.
Huh? The source install you propose *will* result in missing features.
If you just run "cpan PDL" you will not get PGPLOT, PLplot or OpenGPL
graphic. I think that plotting is a key feature, and CPAN will not
give it to you. I know this from experience, after spending many hours
installing PDL in various Linux distributions, just a few days ago.
>From this experience I can tell you a couple of things:
1) Setting up a build environment is different in each distribution.
Some times it is non-trivial.
2) The CPAN intall does not give you everything. After many hours
trying I was not able to get any type of plotting features working on
either Mandriva or OpenSUSE.
Daniel.
--
Intolerant people should be shot.
_______________________________________________
Perldl mailing list
[email protected]
http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
