Thanks much for the suggestions. I didn't install into the system Perl. The MacPorts stuff went into /opt/local/... and that's also where the PDL and PDL::NetCDF went. The MacPorts installed perl is in /opt/local/bin and the pdl in the rather obscure /opt/local/libexec/perl5.12/sitebin. As far as I can tell, the system perl in /usr/bin/perl is intact (with its modules under /System/Library/Perl). But it's dual architecture, which was what caused the trouble. The MacPorts perl is just x86_64, and that was apparently important for the PDL::NETCDF to get installed (my NetCDF library is also x86_64 only). In any case I can always uninstall the MacPorts stuff if I change my mind. I've already done that a couple of times, and it seemed to work, so I'm not so concerned about having another perl in /opt/local. It just seems that there should be a nicer solution. But maybe not. I guess I'll get used to it the way it is.
Thanks, -Stig On Wed, Oct 23, 2013 at 2:02 AM, David Mertens <[email protected]>wrote: > For any POSIX-based system, you should use perlbrew. This way you cannot > accidentally bork your install system's Perl just by accidentally upgrading > a module to a non-backwards-compatible version via CPAN (which has > happened). > > Plus, it's really easy! See http://perlbrew.pl/ > > I must say that I never had any trouble messing with my system Perl, but > I've heard of horror stories. > > David > > > > > On Tue, Oct 22, 2013 at 6:25 PM, Derek Lamb <[email protected]>wrote: > >> > So it's working for me now, but it's probably not the most elegant way. >> I have two perl installations, with some modules installed in >> /opt/local/lib/perl5/, while others are still in /System/Library/Perl. So >> if anyone have better ways, I'll be happy to learn about it. >> > >> > Best Regards, >> > -Stig >> > >> >> A purist would tell you to NEVER install anything into the system Perl. >> If you want to _use_ the system perl, that is fine, but install your stuff >> somewhere else. MacPorts developers would tell you to never install >> anything but MacPorts things into the MacPorts tree (and after awhile, I've >> come to agree with them, the reasons for which could be the subject of >> another email if desired). Taking both of these together, it is advisable >> to put your Perl modules somewhere where neither Apple nor MacPorts can >> touch them. I put mine in ~/local. So anything that isn't in MacPorts >> that I either download from CPAN or install manually ends up in >> ~/local/lib/perl5, my pdl executable is in ~/local/bin, etc. This simple >> setup doesn't allow for versions of modules linked to specific Perl >> verions; I'm OK with that personally. >> >> It's as simple as adding ~/local/bin to your shell's $PATH, setting >> cpan's makepl_arg to "INSTALL_BASE=~/local" and mbuildpl_arg to >> "--install_base ~/local", and remembering to duplicate those on any >> Makefile.PL or Build.PL that you call manually. >> >> Note that I don't think my setup is the purest either: I have 2 >> Apple-built perls (5.8.9 & 5.10.0), and 2 MacPorts-built perls (5.12.4 & >> 5.14.2). I would be happy with one of each, but that's the way it goes >> sometimes. Some people advocate perlbrew, which I also find to be very >> nice. >> >> cheers, >> Derek >> >> >> _______________________________________________ >> Perldl mailing list >> [email protected] >> http://mailman.jach.hawaii.edu/mailman/listinfo/perldl >> > > > > -- > "Debugging is twice as hard as writing the code in the first place. > Therefore, if you write the code as cleverly as possible, you are, > by definition, not smart enough to debug it." -- Brian Kernighan >
_______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
