Some of these can be changed without much hassle, but if you get stuck on a major malfunction, you may find yourself querying Google with the likes of “where is the php.ini for xampp” or “http error 500 *on xampp*”.

The problem with this, I find, is that some problems you encounter may be specific to the packaged stack you chose, and therefore, the “community” (amount of helpful results) is diminished somewhat and you can lose a considerable amount of time trying to source a solution.

I tend to install my stack very similarly to the way Neil has outlined above. It may take a bit longer to install, but I feel that you can save time later by knowing exactly where everything is.

I house everything under “C:\server\” (on Windows), and make a shortcut to here which I can use for my development woes. There are two main approaches I take depending on the particular server “component” (php/mysql/etc) I am installing, which I will coin as “straight” and “versioned” for the purposes of this comment.

With the straight setup, PHP would be installed in C:\server\php\, but, in the versioned setup, PHP might be installed in C:\server\php\5.2.5\. The advantage of the latter is that you can install multiple versions of a particular “component” and switch between them fairly quickly (by editing the correct configuration file [eg. http.conf]).

The “versioned” method is not without the obvious added layer of complexity that comes with longer file paths, but I would only really be recommending it for those seasoned developers who feel they have the need to switch between different versions of server components, otherwise, the “straight” version is more suited for those who simply need a stack! (You can always change it around later)

Here is a quick example of how one might lay out the directory structure of a “straight stack” on Windows:

C:\server\php\
C:\server\mysql\
C:\server\apache\
C:\server\www\ <- set this as webroot
C:\server\www\app1 (a cake app)
C:\server\www\app2 (another cake app)
C:\server\svn\ (svn binaries)
C:\server\cake\1.2-nightly\ (svn checkout)
C:\server\cake\1.2-rc2\ (svn checkout)
C:\server\cake\1.2-rc3\ (svn checkout)
C:\server\etc..

The above can easily be adapted to your tastes, or can be used as the basis for a “versioned” stack by giving certain components subfolders with their corresponding version numbers.

Notice that I have chosen to keep CakePHP outside of my webroot (ie. C:\server\cake\{version}). I can then tell a cake app (ie. C:\server\www\app1\) to use a certain version of CakePHP by adapting the CAKE_CORE_INCLUDE_PATH constant found in {app}\webroot\index.php.

For this, I find it easiest to base this constant from the previously defined ROOT constant in the same file. This is because I use a very similar setup on my live server, where the “cake” directory (which contains the same “versioned” struture) is located in the directory above my webroot.

define(‘CAKE_CORE_INCLUDE_PATH’, dirname(ROOT) . DS . ‘cake’ . DS . ’1.2-nightly’);

This tells my app, that after going three levels up from C:\server\www\app1\webroot\ to define ROOT as C:\server\www\, that it must go up one more level (dirname()) before it will find the cake/1.2-nightly directories.

I will spare you guys any more details, apart from the only shortcuts I tend to use for developing with this setup are:

server: C:\server\
sites: C:\server\www\
ide: {insert ide here}

C:\xampp\apache\conf\extra\httpd-vhosts.conf

I usually create a c:\www directory for all of my development and point my virtual hosts there using my hosts file.

I’ve built Lamp systems in the past and I’ve found this to be the least complicated way.