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.