On 7/4/2010 9:38 PM, P Kishor wrote: > On Sun, Jul 4, 2010 at 8:23 PM, Chris Marshall<[email protected]> wrote: >> On 7/4/2010 8:48 PM, P Kishor wrote: >>> >>> This is likely to be a common reality. For many Mac users, they go to >>> 64-bit via 32-bit (upgrade Mac OS X 10.5.x to 10.6.x). This leaves a >>> lot of custom stuff in the 32-bit world still hanging around. Very >>> unlikely that a user will have a clean machine. For those that do, >>> installs will be a lot easier. >> >> True but PDL cannot fix problems with user systems >> and their private configuration problems. However, >> a clean run through the entire PDL build is necessary >> to diagnose what needs fixing in PDL to support the >> Mac platform. >> > .. > > > Chris, you have used the term "a clean run" or a "clean build" a > couple of times, so I am curious what you exactly mean by that. Do you > mean the target computer should be clean, without any previous > installation of PDL? If so, only someone who has never installed PDL, > has not upgraded from 32-bit to 64-bit, not installed any software > libraries... basically, someone with a brand new computer, updated > with only Apple's updates, decides to install PDL. That kind of a > person would be hard to find. Maybe I will be that, when sometime in > the future I buy a new computer... not for another couple of years.
That is one of the reasons it is difficult to debug installation. If I want to check out the latest PDL I would need to completely wipe my existing installation of PDL. The good news is that by using the PREFIX and LIB arguments it is possible to have PDL installed and usable but non visible for a "clean install test". The bad news, it that is does take at least once through the exercise and you have noted many of the difficulties in setting up for that. I found a very large number of little gotcha's when I started porting PDL to cygwin since I was doing it from scratch and not from a pre-existing setup... > On the other hand, if you mean that the new installation of PDL should > be from a clean source, well, that is what I do. I downloaded PDL > 2.4.6, installed it. A few days/weeks later, I downloaded PDL 2.4.6_11 > in a completely different directory, and tried to build it there. Of > course, I can build it a million times, but until I do a 'make > install' it stays inside its src directory, leaving the current, > working version of PDL 2.4.6 alone. Even this much is useful information. For example, I don't know if you ever got TriD working. As far as I know it should build out of the box for PDL on the Mac. Since I don't have a Mac I cannot verify that myself. If no one reports problems and success, we don't even know what or if things need fixing. > For now, the one that does need fixing is that Makefile for > PDL::Graphics::PLplot. Most users will likely stay away from esoteric > Fortran stuff, but most will want to install some kind of graphics > capability. PLplot seems to be the most mature option (I could be > wrong in that assessment). Fixing that Makefile will really make > things a lot easier. Both the error and the fix are well documented. > They just need to be baked in. We're trying to reduce the cross platform issues for PDL. Reducing the number of different language compilers needed will help with that. Using fortran is definitely a complexity inducer. :-( Thanks always for the thoughts. --Chris _______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
