Please keep this discussion on the list by using the Reply To All
feature of your mail program.
On Dec 18, 2006, at 10:50, js wrote:
Hi Ryan,
Thank you for your reply.
On 12/18/06, Ryan Schmidt wrote:
I am the maintainer of the php5 port. I have not worked on the
problem because I have never observed it. I use php5 +apache2, not
php5 +apache. When I have a moment I will try to install php5
+apache. If there's anything else I need to do to recreate the
problem on my system, please tell me what.
No idea. I didn't try +apache2, so +apache might be the culprit.
-DBIND_8_COMPAT=1 presumably gives you compatibility with bind 8?
What is bind, what version would we otherwise have compatibility
with, and why is 8 better? Is there documentation to support your
position?
What does -DEAPI do?
Isn't -O3 simply adding additional compiler optimization? If so, it
should have no relevance to the problem you are experiencing. Whether
to add -O3 should then be considered separately of this problem. (If
it is of benefit to php5, is it also of benefit to the rest of the
ports? If so, should it be enabled separately? Etc.)
Ah, I see now, you're just quoting the bug report, which is quoting a
user comment on this page:
http://www.php.net/manual/en/install.macosx.php
Unfortunately those user comments do not explain themselves very
much.
You're right. I just read that page and created tha patch, so I'm
not sure
what EAPI really is but today I googled for it and figured out that
Apple's apache is compiled with EAPI support but MacPorts's is not.
$ /opt/local/sbin/httpd -V | grep -i EAPI
$ /usr/sbin/httpd -V | grep -i EAPI
-D EAPI
When you compile a module for apache compiled with EAPI,
you need to tell the module of the fact .
(Another quotation from
http://groups.google.com/group/php.general/browse_thread/thread/
a106772d439646ca/dc901640028be3b6)
So if you use MacPorts's apache, probably you don't need -DEAPI, but
you might want -DEAPI if you use Apple's. (Not tested.)
Interesting! Thanks for looking that up.
This is a second issue (which unfortunately seems to be mentioned in
the same MacPorts bug report). It changes the php5 +apache variant.
Currently, php5 +apache uses Mac OS X's provided Apache server. After
these changes, it would use the MacPorts apache port. There has in
the past been a request to offer both variants: a way to install
using Apple's Apache, and a way to install using MacPorts' Apache. I
would be in favor of a patch to implement this suggestion. I would
like to see precedent for other ports that have options both for
using Apple's version of something and the MacPorts version, and I
would like to then follow the same variant naming conventions.
Someone interested in seeing such a patch applied should do this
research and report back.
To me that change seems wrong idea, I'm afraid.
As you said in the other mail,
"MacPorts philosophy has always been to
build its own versions of software, and not use any versions Apple
may already have installed with the OS"
If so, why don't you use MacPorts's one by default?
By "by default" do you mean "when you use the +apache variant"? If
so, I agree with you, from the other thread you quoted. However, I
wanted to note that this seems to be a completely separate issue from
the one you originally mentioned.
besides, who want to use Apple's old, not so well maintananced
apache?
A month or two ago, I proposed eliminating the ability to use Apple's
Apache and only use MacPorts's Apache. Several people objected to
this, which is why I proposed the compromise in which both are
available.
Some reasons to prefer Apple's are that it gets auto-upgraded by
Software Update, and that you can control it from System Preferences
> Sharing > Personal Web Sharing. With the MacPorts version, you
have to use the terminal for both tasks, something some users are not
comfortable with.
_______________________________________________
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-users
