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](http://xdebug.org/) 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](https://bugs.php.net/bug.php?id=45114) 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](http://www.85qm.de/archives/727-Zend-Debugger-for-PHP-5.3.html) 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](http://www.zend.com/en/community/pdt).
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 `ZendDebugger.so`. 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.
