Code and Hacks

Stuff I've stumbled on or figured out... mostly Perl, Linux, Mac and Cygwin.

My Photo
Location: CA, United States

Perl hacker, investor and entrepreneur.

Wednesday, October 14, 2009

Moving to a Mac... which Perl?

We'll after neglecting this blog for quite some time, I'm now back. I had to swap my laptop during the summer, and I decided to give one of the MacBook Pros a try. So I'll be adding Perl on the Mac and the Mac in general to the topics covered here. My first dilemma with the new Mac was which perl to use.

  • Leopard only had 5.8 installed, and I've been hooked on 5.10 for a while now. (Snow Leopard has added 5.10, but by the time I got the upgrade I was commited to the ideal of keeping the system perl separate from my development perl.)
  • Having come from Arch Linux, I stumbled upon and really liked Arch OS/X. Unfortunately, it appears that it isn't as well tested as MacPorts. In order to build any Perl modules that us XS with the Arch OS/X perl, I needed to use:
    $ perl Makefile.PL \
        LDDLFLAGS="-arch x86_64 -arch i386 -arch ppc \
                 -bundle -undefined dynamic_lookup -L/usr/local/lib" \  
        LDFLAGS="-arch x86_64 -arch i386 -arch ppc -L/usr/local/lib" \
        CCFLAGS="-arch x86_64 -arch i386 -arch ppc -g -pipe \
                 -fno-common -DPERL_DARWIN -fno-strict-aliasing \
                 -I/usr/local/include -I." \
    Ummm... I don't think so! While I created an bash alias for it, cpan/cpanp where requiring constant tweaks. I assume I could have exported those variable from my bashrc, but I would rather avoid global changes like that.
  • Next I tried compiling my own perl. I ended up doing it several times as I learned where to put it, and realized I had forgotten to enable things like threads. This really seems to be the best way to go, but I would rather someone else keep up with security patches, new versions, etc.
  • So finally I tried MacPorts. So far so good. I have had trouble remembering to check the variants (port variants <port-file>), but otherwise thumbs up.

One thing I realized that I want, is a record of all the ports that I have installed (not a list of all the installed ports, just those that I had purposely installed). So, I wrote a short bash script that I stuck in ~/bin/port to keep a log:


case "$1" in
  install|uninstall|upgrade|activate )
      echo "`date` $@" >> ~/.macports.log

/opt/local/bin/port $@

Now anytime I run port install perl5.10 +shared +threads it is added to a log file. Rebuilding the system should be a snap. (I'm sure I could have gotten this by grepping for sudo and port install from the /var/log/system.log* files, but I like having it all in one place and not worrying about log files being rotated out.)

One other tweak I need to make, was for CPANPLUS. I wanted to be able to install modules in either the system perl (by running /usr/bin/cpanp) or the MacPort perl (/opt/local/bin/cpanp), but both of those read my user config file (~/.cpanplus/lib/CPANPLUS/Config/ which need a full path for perlwrapper => '/usr/bin/cpanp-run-perl'. So I moved just that part of the config to the system config file by runnning the following in each cpanp:

$ s save system
$ s edit system

Then removing everything but the perlwrapper configuration. And finally taking the perlwrapper configuration out of my file. One other thing I needed to do to make 5.10 the default perl. MacPort defaults to perl5.8, but the following took care of that:

$ cd /opt/local/bin
$ sudo mv perl perl.bak
$ sudo cp perl-5.10 perl
# make cpanp -> cpanp-5.10, etc.
$ for i in *-5.10 ; do x=${i%%-5.10} ;  sudo mv $x $x-5.8 ; sudo ln -s $i $x ; done 

I see Python has a python_select port-file. Maybe we need something like that for Perl.

Labels: , ,


Blogger nothingmuch said...

building your own Perl is incredibly easy.

I keep /usr/local owned by my user, and then just run:

./Configure -de && make install

If i need threads, -Dusethreads

I also use -Dversiononly to keep separate versions installed.

This way I never run sudo to mess with installations, and therefore never worry about screwing up my system perl, which other things may rely on.

The way I see it security patches are not a concern.

This is my laptop, it's neither extremely vulnerable (it's not providing services to any potential attacker), nor is it valuable for an attacker.

My time is much more valuable for me.

If I want to upgrade Perl I do it when it's convenient for me, instead of when my upstream vendor has broken something (c.f. Apple's downgrade of Storable for system Perl).

Vendors tend to prioritize security updates because they are "important", when in fact for my day to day work simple bug fixes are *much* more valuable. Wasting time trying to monkey patch a vendor's version of a buggy library is a lot more hassle than just doing it myself with

Being able to do that safely and reliably is invaluable as a Perl developer.

This may be a bit more risqué but I do the same for production machines as well, building a separate version of Perl for every deployed application. This keep things separate so I can upgrade the dependencies of one application without worrying about the others.

Lastly, some people I know use Debian in a virtual machine on their macs, because Debian's package management lets you easily build packages yourself, with a much lower risk of hosing the system. This gives you the ease of use of a package manager, with the relative reliability of rolling your own.

October 13, 2009 at 8:02 AM  
Blogger Aaron said...

Another alternative is ActivePerl for Mac OS X, which comes in a .dmg and feels very Mac-y, although it is certainly not as flexible.

October 13, 2009 at 8:54 AM  
Blogger Brian said...


Unless you are using the same modules on a leopard system, you can drop the "-arch ppc" portion of your variables.

Since Snow Leopard doesn't run on PPC it does not make a lot of sense to build that arch unless you need to.

October 13, 2009 at 10:42 AM  
Blogger matt said...

I like the flattened lib structure posted here:

October 13, 2009 at 9:03 PM  
Blogger Mark said...

@nothingmuch: I really like the idea of having the /usr/local perl owned by me. If I stick with macports, you've got me thinking about changing the ownership on the entire /opt/local.

While I was very comfortable with root on a linux box, I feel like there is a good chance I am messing something up every time I type sudo in OS/X. Hopefully that feeling will go away as I get more comfortable.

October 14, 2009 at 5:55 AM  
Blogger Mark said...

@Aaron: I hadn't seen ActivePerl for OS/X, thanks. I had used ActivePerl on a windows box, but I ended up using cygwin's version.

October 14, 2009 at 5:57 AM  
Blogger Mark said...

@Brian: Thanks for the correction. I clearly cribbed that from somewhere (not sure where anymore).

October 14, 2009 at 5:58 AM  
Blogger Mark said...

@matt: The one perl per application idea is very interesting. I spent a bunch of time beating my head against local::lib trying to bundle the dependencies for my catalyst app recently. (I had planned to post about that in the next few weeks.)

The only catch is that I still rely on packagers (MacPerl or Arch Linux, in my case) for certain hard to install modules. Things like ImageMagick and WxWidgets jump to mind.

October 14, 2009 at 6:10 AM  

Post a Comment

Subscribe to Post Comments [Atom]

<< Home