Debugging with MacPorts PHP binaries and Eclipse PDT 3.0

You know the times, when things should really go fast and easy, but you fall from one nightmare into another? Tonight was such a night… but lets start from the beginning.

To debug PHP you usually install the excellent [XDebug]( and so did I with the port command `sudo port install php5-xdebug`. After that `php -v` greeted me friendly on the command line already:

PHP 5.3.8 (cli) (built: Sep 22 2011 11:42:56)
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies
with Xdebug v2.1.1, Copyright (c) 2002-2011, by Derick Rethans

Eclipse Indigo and Eclipse PDT 3 was already installed, so I thought it should be easy to set up the XDebug debugging option in Eclipse. Under “PHP > PHP Executables” I therefor selected `/opt/local/bin/php` as my CLI version and selected “xdebug” as debugging option.

A first test however showed me that the execution of a test script did not load any module into the PHP interpreter beforehand (for reasons I could only guess, because Eclipse error log kept quite). Looking at the output of `phpinfo()` from my test script and `php -i` from command line showed me the difference: The PHP option “Scan this dir for additional .ini files” was empty when PHP ran inside Eclipse, but was properly set when PHP ran from command line (or in an Apache context).

Asking aunt Google brought up [this issue]( that shed some light into my darkness: The directory where additional modules reside is configured as a compile time option in PHP and defaults to `/opt/local/var/db/php5` on MacPorts and exactly this can be overridden by either calling PHP with `-n -c` options or by setting the `PHP_INI_SCAN_DIR` environment variable.

Having no access to the actual PHP call from inside Eclipse I tried to go down the environment route, but that did not lead to any success. While the variable was recognized as it should on the normal command line (e.g. `PHP_INI_SCAN_DIR= php -i` disabled the load of additional modules), in Eclipse’ run configuration dialog, in the section environment variables, this was not recognized at all. I tried a little harder and configured the variable inside `~/.MacOSX/environment.plist`, logged out and in again, restarted Eclipse obviously, but had no luck either.

The only viable solution I came up with was to place all the single `extension=` and `zend_extension=` entries directly into my `php.ini` and disable the individual `module.ini` files altogether. At least I can now run and debug properly, but this solution is of course far from being ideal – as soon as I add a new PHP module or want to remove an existing, I have to remember to edit the `php.ini` myself.

By the way, I also tried to use Zend’s debugger (and PDT plugin) as an alternative. [While somebody else]( already ranted about that the Zend guys have been unable to provide the Zend Debugger for PHP 5.3 as a standalone download (which hasn’t changed to date), PHP 5.2 debugging worked nicely with [the old Zend PDT plugin](

Of course, none of my needed PHP modules were loaded and I really needed PHP 5.3 support, so I had to follow the same route the other guy did and downloaded all of the ZendServer glory (a 137MB download, yay) just to get the right ``. After extracting the `.pax.gz` archive from the installer package I quickly found it underneath `usr/local/zend/lib/debugger/php-5.3.x/`, copied it to my extension directory and added an ini file to load that one instead, just to find out shortly afterwards that the Zend binary was `i386` only and MacPorts of course compiled everything nicely as `x86_64` – php was of course unable to load such a module.

Well, the moral of the story is – go for Xdebug and don’t loose the track. And, let us all hope that Eclipse PDT is developed further, so the remaining glitches like the one above are fixed.

Taxbird nun in MacPorts verfügbar

Der ein oder andere kennt [Stefan Siegls]( kleines Programm [Taxbird]( eventuell schon: Es erleichtert Selbstständigen unter Linux die Abgabe von Umsatzsteuervoranmeldungen gegenüber dem örtlichen Finanzamt.

Mac-User blickten jedoch bislang weitesgehend in die Röhre, da der offizielle Elster-Client bis heute nur unter Windows verfügbar ist. Da die Komponenten von Taxbird (die mit Gtk geschriebene GUI und eine Bibliothek zum Datentransfer, die auf den passenden Namen “libgeier” hört), Standard-Bibliotheken und Tools benötigt, habe ich mich an einen Port gemacht und diesen [heute fertiggestellt](

Wer das ausprobieren möchte, der möge einfach `sudo port install taxbird` ausführen. Beim ersten Start erkundigt sich Taxbird nach `html2ps`, welches optional zur Übersetzung des HTML-Reports in PostScript genutzt werden könnte. Ich habe hierfür bislang auf einen weiteren Port verzichtet, da html2ps weder über eine Standardinstallationsroutine verfügt und außerdem etliche weitere Abhängigkeiten mit sich bringen würde. Die HTML-Reports sollten daher vor dem Versand einfach abgespeichert werden.

Feedback ist willkommen!

openSUSE build service client ported

I used to create packages for a couple of open source projects for the openSUSE Linux distribution. They have this really nice build service running on, on which you can – despite of its name – also build packages for other Linux distributions like Fedora, Gentoo or Debian.

While the web-based interface of the service is nice, some configurations and local builds require their command line client osc though, which is python-based and works similar to subversion. This client however was only packaged for the main distros the build service itself supports, but was unavailable for others like f.e. Mac OS X, so I created a MacPort for it today (installable via sudo port install osc).

Of course local Linux builds are not possible with it, as we’re missing the complete environment, but I think its still useful for maintaining and managing remote builds on the service itself. Have fun with it!

monotone-viz [updated]

I’ve recently packaged monotone-viz 1.0.2 for MacPorts (and soon also for openSUSE), a program to display monotone’s DAG of revisions and their properties. This becomes very handy if you need to do a complex (asynchronous) merge or you want to know what exactly monotone has merged together for you. One example is the graph of the “merge fest” we’ve had in spring 2008 for the last summit you see on the right.

complex merge in monotone

(Source: monotone website)

Merging in monotone is actually quite robust; while I’ve had a lot of “fuzzy” feelings in the past when doing complex merges with subversion or even CVS, merging in monotone is a no-brainer. It most of the time does exactly what you want it to do. One exception here is the handling of deleted files however, also known as “die-die-die” merge fallout: If you merge together two distinct development lines where one file has been edited on the left side and deleted on the right side, the deletion always wins over the edit, and there is absolutely nothing you can do against it (well, despite re-adding the file after merge and loosing the file’s previous history). Thankfully this is not such a common use case and keeping an “Attic” directory where deleted, but possibly revivable files reside is the medium-term solution, until someone picks up the topic again.

But back to monotone-viz, I couldn’t fix one problem with monotone-viz on MacPorts: It doesn’t properly draw the arrows on the graph, but rather puts them above the revisions, like this:


I’ve already asked the author about it, but he couldn’t find out whats wrong, so I suspect something is wrong with my gtk+ setup. If you have a hint for me where to look at, give me a pointer, I’d be very thankful. And if you tell me that it works correctly for you, then even better, drop me a note as well. I’ve uploaded a test monotone database with a simple merge to test the behaviour. Thanks!

[Update: As this bug points out the render problem comes from Graphviz’ dot program – hopefully the patch will made it into a new release shortly.]