Edin Kadribasic wrote:
It's realy very logical. It leaves the default installation the way most people will expect it to behave, which is as it has been for years now. Having the options allow people to modify that behaviour to the way they want it to work. It's very flexable for all interests.* On other platforms, the cgi *is* installed by 'make install' by default. To install cli something like, 'make install-cli', or 'configure --install-cli=[DIR] --install-cgi=[DIR]' can be used (the second option would be more usefull for installing both, using both without [DIR] on one results in a configure error). A note regarding what was installed and where should be added to the output resulting from an install.I really don't understand why insist on cgi being installed on "make install" to ${PREFIX}/bin? The solution outlined by Andrei and Derick is much better IMHO because it will alert users of the issue and because installing a cgi into a webserver requires manual action anyway.
None of the reasons I have seen listed against this are insurmountable. The *only* reason I have seen (ie. remember at this moment) that comes close to convincing me otherwise is the one that you stated:* Binaries are combined into a single binary in a later release. I'd be happy to do this in January.-1 for reasons i stated in my reply to Andrei.
"In practice this would mean that one would be unable to run php
command line scripts from within webserver environment, through system()
call from other cgi/php scripts etc."
The problem is that cli was started as a seperate binary and no thought was put into having things work as a single binary. I'm not convinced that there isn't a way around the system() issue yet...but you may have a point. It could be done by using a flag in that instance (php -f script.php for instance) but that is not optimal.
Shane
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
