I've looked those over before, wasn't impressed with a lot of it
perhaps you could contribute comments to improve the directions -
rather the
point of a wiki afterall...
It's less time consuming for me to recommend not following those
instructions rather than correct the multitude of flaws.
however for the user who has no real programming experience MAMP does
make life a little easier as long as you don't mind installing some
software that isn't as functional as what apple already provides and
don't mind having multiple installations of the same software wasting
disk space.
Sure you can install other versions of PHP and other parts and
pieces. And any
update from Apple can change that installation or configuration at
any time.
Not if your installation/configuration is designed to work with and
enhance the software that apple provides.
I have generated such add-on packages for folks in the past, when
10.4.1 was first around, they are still using the same software
despite the changes that apple has made and software update hasn't
affected the extensions so your point regarding updates is only valid
if you don't plan your work properly.
Apple never provided a /etc/php.ini file so the only issue would be
that apple decided to install an /etc/php.ini file with customized
settings overwriting the users installed and configured file and
they'd have to be total idiots to do something like that.
That's what MAMP is designed to avoid.
It's a trade off of convenience over disk-space and lack of
knowledge, it certainly isn't efficient by any means.
But it's hardly the core of the directions outlined there.
The problem with directions like that is that they don't take
advantage of any additional functionality that might be present in
the provided software and because the author assumed that the
installation was generic in nature and thus as an exercise in
ignorance decided to include his version or instructions to generate
his version.
Like building and installing the following libraries for GD support:
libpng
libjpeg
libtiff
libpdf
libgiff
Sadly enough everyone wants these libraries and of course I provide
them when the customer requests them and can't grasp the concept that
they are not required however, I have the same support in GD without
adding these libraries because they are already available in the
system and all I had to do was write a couple of header files to re-
map some function names that apple has changed and create a couple of
symbolic links to use what apple has provided and I have absolutely
no compatibility issues and I don't waste disk space installing
software that is already provided and I've not experienced any issues
since I generated the build in 10.4.3 and updating to 10.4.8.
Doing this only took a few minutes, all that was required was to
extract the function names (apple gives you tools for this) and then
re-reference them for use in a custom header file and create a couple
of symbolic links.
Now if apple updates these libraries and the API changes, they
provide a new build version and change the "Current" symbolic link
otherwise any existing applications would no longer work and the only
software that would run would be apple supplied.
Oh, and the freetype supplied in apple's X11 will outperform the
generic build any day.
