Sean Coates

My old post on compiling PHP for Mac OS 10.5 (Leopard) continues to top my most-viewed page statistics. Sadly, that article is old and doesn't apply very well to Snow Leopard (10.6).

I've been meaning to post instructions on how to compile PHP for Snow Leopard since last summer when I picked up the DVD, but hadn't found the time or opportunity to build PHP from a completely fresh start, until a few weeks ago.

This time, I took notes on how to reliably compile PHP and Apache from scratch on this system.

1. Download and install Xcode. You're on your own for the details of this one, but frankly, if you can't figure it out, you'll find the next steps too difficult. Think of it as a prerequisite.

2. Create a working directory. I use ~/src, but you can use whatever you like.

   
   $ mkdir ~/src
   $ cd ~/src
     

3. Install Homebrew. Homebrew is a truly great software packager for OS X. Think Macports, but not as ugly; Fink, but not as broken (and not as binary). Designed for Mac. It's Ruby, but we don't have to hold that against them. (-:

   
   $ curl http://gist.github.com/raw/323731/572b315c4f7ee78244de70e7ad703c8ae324da7a/install_homebrew.rb > install_homebrew.rb
   $ ruby install_homebrew.rb
      

4. Install your own iconv. I don't know what Apple did to theirs, but it's a huge headache. You're best installing your own, in my experience.

   
   $ curl http://ftp.gnu.org/pub/gnu/libiconv/libiconv-1.13.1.tar.gz | tar -zx -
   $ cd libiconv-1.13.1
   $ ./configure --prefix=/opt && make && make install
   $ cd ..
     

5. Install Apache-HTTPD from source. This isn't absolutely necessary, but Apple seems to have done some weird stuff with their Apache, and in my experience, it's best to build your own. If you skip over this step, you'll need to change the apxs in the PHP configure command, below.

   First, find your closest mirror.

   
   $ curl http://apache.mirror.iweb.ca/httpd/httpd-2.2.15.tar.bz2 | tar -jxf -
   $ cd httpd-2.2.15/
   $ ./configure --enable-rewrite --enable-ssl && make && make install
   $ cd ..
      

6. Install PHP dependencies using Homebrew. Easy, huh?

   
   $ echo "gd jpeg libpng libxml2 libzzip mcrypt mysql" | xargs brew install
   $ echo "libpng libxml2 readline" | xargs brew link
     

7. Install PHP from source by first selecting a mirror.

   Note: you will need to use a really nasty patch to get this to build properly. See the note on iconv above. Even Apple's own iconv patch for PHP doesn't work (at least not for me).

   
   $ curl -L http://ca2.php.net/get/php-5.3.2.tar.bz2/from/this/mirror | tar -jxf -
   $ cd php-5.3.2
   $ curl http://www.php.net/~scoates/patches/php-5.3.1-Makefile.global-iconv.patch | patch -p0
   $ ./configure --prefix=/usr/local --with-xsl --with-gd --with-zlib-dir \
     --enable-sockets --enable-exif --with-mcrypt --enable-soap \
     --enable-embedded-mysqli --with-mysql --with-pdo-mysql --with-curl \
     --with-libedit --with-apxs2=/usr/local/apache2/bin/apxs --enable-mbstring \
     --with-openssl --with-iconv=/opt && make && make install
   $ cd ..
     

8. Configure Apache. If you've done this on other platforms, this step should look familiar.

   1. In /usr/local/apache2/conf/httpd.conf, in the <IfModule mime_module> block, add the following:

      
      AddType application/x-httpd-php .php
      AddType application/x-httpd-php-source .phps
          

   2. Optionally, add PHP to DirectoryIndex by changing

      
      DirectoryIndex index.html
          

      to

      
      DirectoryIndex index.php index.html
          

   You can now test Apache + PHP by creating a phpinfo() page, and restarting Apache:

   
   $ echo "<?php phpinfo(); ?>" > /usr/local/apache/htdocs/info.php
   $ ln -s /usr/local/apache2/bin/apachectl /usr/local/bin/apachectl
   $ sudo /usr/local/bin/apachectl restart
     

   Now, visit localhost/info.php, and you should have an independent, custom-compiled Apache-PHP stack.

I hope this has been helpful. If I've given bad instructions, or if something doesn't work for some reason, please let me know in the comments.

Belorussian translation provided by Patricia.

I have a love-hate relationship with Adobe AIR.

On the positive side, AIR allows developers who are primarily experienced in web technologies (such as myself) to apply existing skills to the creation of GUI applications with a minimum of additional deployment-specific competence, and to release those apps on several platforms, in parallel.

This shallow learning curve has facilitated the creation of GUI apps that would never have otherwise graduated beyond a passing thought by their creators.

A good example of this is Spaz, my currently-preferred interface to the Twitter. Ed, its author, and my friend, is well-skilled in web technologies and I suspect that both the application of HTML and JavaScript to GUI deployment, and platform independence, were key factors in choosing AIR as Spaz's platform.

Is platform independence and portability really a good thing? I do think so, but I also think that special care must be taken to conform to the target platform's established conventions. This is where AIR fails (but where other similar—but not the same—platforms such as RealBasic, XUL and (dare I say it?) yes, even Java do a better job).

I've been sitting on this rant for a long time, and it's come up with several people in the past few weeks, so once again, I'm blogging about it as time allows. Sorry if these thoughts seem incomplete. Truth is that some of them are, but I want to get something written down.

Widgets, Controls and Placement

One of the first things you'll notice if you run several AIR apps concurrently is that they all look different. Take a peek at this article on "8 AIR apps that don't suck", for screen shots. All eight of these apps are visually appealing in their own way (this is subjective, of course), but that's the key: in their own way.

A lot of care and money has been spent on research and development of the major GUI interfaces, especially by Microsoft and Apple. With few exceptions where the AIR author has opted to adopt the system's native GUI, at least for the basic window chrome, these applications have reinvented the wheel.

I've read that AIR makes it very hard to emulate the system look and feel for standardized UI widgets. It is especially difficult in HTML-based apps, because the version of webkit they ship will not allow you to modify the look and feel of some form widgets (selects, radio buttons) or the scroll bars. You have to roll your own widgets entirely if you want to change the look of these. Adobe allegedly does this is on purpose. They want apps to look the same on their platform—the Adobe Flash platform—and to look and behave identically on all OSes.

As a user, this is confusing. Not confusing to the point where I don't know how to use the 7 different types of scrollbars displayed in these 8 applications (hint: WebDrive's screenshot doesn't display a scrollbar), but the lack of established convention is visually distracting at the very least.

Buttons, menus (I didn't know that the "Spaz >>" button was actually a button for the first few months I used the app; maybe I'm just an idiot), scroll bars, handles, "grippies", toolbars: these controls have been well-defined by our window managers and operating systems. Is it really worth the inconsistency just so you can be more visually appealing (and often fail at this)? I don't think it is.

(I wrote a short piece on this a while back, and many of the same assertions apply.)

Inter-application Consistency, Established Conventions

The previous point leads directly into this one: AIR apps are generally terribly inconsistent, not only between each other but also with the native toolkit.

Here are some conventions that apply to (almost) every application I currently have open on my Mac, but rarely apply to AIR apps:

• Window close button is at the top left corner of the window
• Toolbar at top of window (if applicable); button at top right of window hides this toolbar
• Scroll bars are clickable outside of the control bar, buttons to increase/decrease scroll are both at the bottom of the scroll bar
• Pressing cmd-, opens the application's preferences dialog
• Double-clicking the application's title bar "minimizes" the application to my dock (I actually dislike this, but at least it's consistent in native apps)
• Pressing cmd-z causes the "undo" event to be fired; this is built in to the toolkit for controls like text boxes

With the exception of cmd-, (which the author has explicitly definied in the code), Spaz does not conform to any of these conventions. Do I think this is Ed Finkler's fault? No, I don't. At least not entirely his fault...

Adobe seems to have adopted a different consistency regime than what I believe to be the right solution. It appears that they're more concerned about AIR apps looking exactly the same on each platform, than for those apps to conform to their platform.

Operating System Conventions

Admittedly, the convention I'm about to mention is only a de facto standard; not officially endorsed by Apple.

I love Growl. It works well, and adds much needed consistency to application notifications. I even use it to tell me the caller ID when my home phone rings. With the possible exception of a recent AS3 Growl library, AIR apps have been painfully unable to easily generate Growl notifications (due to improper application sandboxing, in my opinion), and I know this has been a major point of contention for Spaz's author (we've discussed it several times, and I think I was even tasked with solving it, last summer, but no time... no time).

Worse yet, Adobe has "conveniently" built Notification support into the AIR platform. This sounds good, until one discovers that the notification support has been created from the ground up, and doesn't hook existing conventions. I suppose this was necessary on platforms that don't have a widespread system like Growl, but for us Mac users, it's outright annoying.

Applescript and Accessibility

On to the final point of my rant...

Last weekend, I attempted (and failed for several reasons) to write some AppleScript that would allow automated repsositioning of most of my applications when I change display configurations from laptop to desktop.

I was not surprised to find that Spaz didn't have an AppleScript dictionary (is AppleScript dying? I'm starting to think so...), but worse, it didn't respond to a standard request: tell application "Spaz" to get the bounds of the first window (results in an error). I found a workaround (sort of), but this just illustrates AIR's neglect when it comes to abiding by system conventions.

I can only imagine how badly these things must play with accessibility software. Are visually impaired users able to use screen reading software with AIR apps? Spaz certainly doesn't play well with VoiceOver. Perhaps my colleague and friend Jon Gibbins can shed some light on the accessibility issue.

All this to say: I'm quite fed up with AIR apps. The lack of convention with my regular workflow has gone from annoying to downright disruptive, and I'm on the verge of abandoning them entirely, if something isn't done to promote platform conformance... and I suspect I'm not the only one.

Thanks to Ed Finkler for giving me some feedback on this rant. I greatly respect his opinion in this area, and he gave me some excellent additional points that I need to think about, especially why I think it's OK for web sites to have a more freeform canvas than desktop apps (though I do think that it's even more evil for web sites to reinvent their toolkits). Some thoughts published, yet more filling my head...