PHP on Snow Leopard: 5 ways to win

There’s at least five ways to install PHP on Macosx 10.6 Snow Leopard. Probably more.

This becomes important when you as a developer want to add some code or a module to your application. You need to know:

1. Where to install said module.
2. How to configure the appropriate runtime to find and execute said module.

In my case, I want to run phpunit from the command line, and I want to have the FirePHP development tools available for web application development. If your development environment (or mine) was configured exactly as the environment of the people who wrote these tools, installation and operation would be a snap. Just follow the instructions to the letter.

If your environment is like mine, that is, different from theirs, you might need to know how all this actually works. You might need to know which PHP interpreter is running for which task, where it’s configuration files are located, and how to obtain all that information as fast as possible.

Because there is nothing worse than pounding away on a configuration file, and seeing nothing happen, until you realize it’s the wrong file.

5 ways to run PHP on MacOS X

Here’s at least five ways to handle PHP on a Mac:

1. Bundled: Since Macos 10, PHP has shipped with the operating system. This php runs from /usr/bin.
2. Tarball (source): In some ways, installing PHP from source is the easiest and most reliable way to install and maintain PHP. You always know what you have, where it’s located, and how it’s configured. You have to. Can’t run it otherwise.

   However, running PHP from a source installation requires you to keep up with changes in associated tools such as MySQL and Apache. Smart developers will run a testing environment before committing to toolchain changes.

3. Macports: The standard way to bring the unix toolchain seems to be Macports. In the past, Fink received a lot of attention, and the in future, Homebrew may be the preferred method. At the moment, Macports.
4. Homebrew: I’m not running Homebrew, so I’m not going waste your time writing something I don’t know anything about.
5. MAMP: Getting a Mac-Apache-MySQL-PHP stack up and running is really fast using MAMP. Download, install, you’re pretty much done. The key is understanding how MAMP is configured. In a nutshell, it carries all it’s own configuration in the /Application directory, rather than distributing files over /usr/local, /opt and the like.

We’ll take a closer look at all of these next.

MacOS X bundled PHP

Snow Leopard, Leopard, and probably at least earlier version of MacOS X ship with a PHP interpreter installed as a native runtime. Whether this is convenient or not depends on what you want to use it for. At the time of this writing (February 23, 2011), the version installed on my development Macbook is 5.3.3.

• Question for you, the reader: Does Apple upgrade installed versions of PHP during software upgrades?

I believe they do, and running php –version tells the story:

1
2
3
4
5

$ /usr/bin/php --version 
PHP 5.3.3 (cli) (built: Aug 22 2010 19:41:55) 
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
$

I bought this Macbook in April 2010, so at some point, the PHP executable was updated. Good to know.

From the tarball

Getting PHP source is easy, just download from php.net. I always like to unpack tarballs into a tmp directory, inspect the structure of the directory, then move it into, say, ~/src/ to build and install. Being a big fan of keeping a clean system, for local development, I like to install into my home directory as so:

1
2
3
4

$ ./configure --prefix="$HOME/local"
$ make
$ make test
$make install

The result puts the entire PHP runtime into your ~/local directory. Very handy. It’s also handy to copy the output from install to see where everything ended up. Here’s the output from my make install:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

$ make install 
Installing PHP SAPI module:       cgi
Installing PHP CGI binary: /Users/daviddoolin/local/bin/
Installing PHP CLI binary:        /Users/daviddoolin/local/bin/
Installing PHP CLI man page:      /Users/daviddoolin/local/man/man1/
Installing build environment:     /Users/daviddoolin/local/lib/php/build/
Installing header files:          /Users/daviddoolin/local/include/php/
Installing helper programs:       /Users/daviddoolin/local/bin/
  program: phpize
  program: php-config
Installing man pages:             /Users/daviddoolin/local/man/man1/
  page: phpize.1
  page: php-config.1
Installing PEAR environment:      /Users/daviddoolin/local/lib/php/
[PEAR] Archive_Tar    - installed: 1.3.7
[PEAR] Console_Getopt - installed: 1.2.3
[PEAR] Structures_Graph- installed: 1.0.3
[PEAR] XML_Util       - installed: 1.2.1
[PEAR] PEAR           - installed: 1.9.1
Warning! a PEAR user config file already exists from a previous PEAR installation at '/Users/daviddoolin/.pearrc'. You may probably want to remove it.
Wrote PEAR system config file at: /Users/daviddoolin/local/etc/pear.conf
You may want to add: /Users/daviddoolin/local/lib/php to your php.ini include_path
/Users/daviddoolin/src/php-5.3.5/build/shtool install -c ext/phar/phar.phar /Users/daviddoolin/local/bin
ln -s -f /Users/daviddoolin/local/bin/phar.phar /Users/daviddoolin/local/bin/phar
Installing PDO headers:          /Users/daviddoolin/local/include/php/ext/pdo/

NOTE: after you build and install, the which command may show the preferred executable, which won’t run until you rehash your shell. For example, I run $HOME/local paths before system paths. After this build, php --version returns PHP 5.3.3 (cli) (built: Aug 22 2010 19:41:55), but the version built is 5.3.5.

You can see this by opening a new shell, which will return 5.3.5 as desired. Or run hash to update paths.

Looks like there might be an issue with my .pearrc file. Here’s what’s in it right now:

1
2

#PEAR_Config 0.9
a:1:{s:10:"__channels";a:6:{s:12:"pecl.php.net";a:0:{}s:5:"__uri";a:0:{}s:11:"doc.php.net";a:0:{}s:15:"pear.phpunit.de";a:0:{}s:16:"components.ez.no";a:0:{}s:24:"pear.symfony-project.com";a:0:{}}}

This is my first time digging into PEAR in any depth. As luck would have it, the first chapter of Packt’s book on PEAR is published on the web:

• The PEAR Installation Manifesto.

Supposing the .pearrc file needs to be replaced, it’s probably as easy as changing the version number, commenting out the existing line of JSON, and adding a new line of JSON. In other words, no big deal.

Macports

Macports is a really easy way to create a full-blown unix toolchain. In this case, PHP is install in /opt/local/bin/php.

MAMP

Since the “P” in “MAMP” does stand for PHP, it’s time to poke around there as well. MAMP is interesting as it install everything into subdirectories of /Application/MAMP. This could be convenient, it could be infuriating; depends on your point of view. I choose to regard it as convenient.

Looking ahead to PEAR

Because the PHP system on my Macbook was initially brought up using Macports and sudo, updating the .pearrc file requires either roots privileges, or a change of ownership:

1
2
3
4
5

$ pear channel-discover pear.phpunit.de
no write access to /Users/daviddoolin/.pearrc!
$ ls -l ~/.pearrc 
-rw-r--r--  1 root  staff  213 Dec 20 19:24 /Users/daviddoolin/.pearrc
$ sudo chmod 644 ~/.pearrc

We’ll go deeper into PEAR later; here are some notes:

Use locate pear to get a long list; extract the locations for the PEAR command from that list.

PEAR doesn’t appear to be installed by default on MacOS X. It is, however, installed by default when you build from source.

For all PEAR installations on your development machine, issue a pear config-show. This will show you where all the options are for that installation. If you have PEAR in several places, you may find the options are all different as well. Know which one you’re using when you install and upgrade your system!

For more information:
Start here: PEAR dot net.
Then proceed stepwise through: Installation instructions.

Summary

This is at 1100+ words already, it’s time to get this post out there into the world. Otherwise it could easily turn into another 2000, 3000 words. There really are a lot of dark and dusty corners in the house of configuration.

If you’re having a PHP configuration issue, leave a question in the comments. I may well be able to help.

Tagged as: Configuration, PHP, Web application