> > What is wrong with adding a third parameter to PHP_EXTENSION? If you take a > > look at the patch, you will see that I need to create a list of libraries > > that is only built with cli. I don't know how to do that with the two macros > > you added. > > you tie ext/pcntl to a certain sapi although it should be available for > a certain class of sapis, the standalone ones > ext/readline and ext/ncurses are similar cases, they are only usefull > in interactive sapis
If you take a look at the patch, you will see that this is exactly what it does -- it binds the extension to a class of sapi's. In this case cgi and cli. > until now both classes had only one member, the cgi sapi > right now they have two members, cgi and cli, although cgi > should be thrown out as soon as cli is done and ready, Cgi is very usefull thing to have and it shouldn't be removed. It's just that is not well suited for command line scripts. > but what do we loose if we prepare for additional interactive/standalone > sapis by using the checks i added so that we have to do changes in only > *one* place instead of changing the calls to PHP_EXTENSION all over > the place (not to speak of extension not even in the php4 CVS)? Sorry, I forgot to mention that the third parameter is optional so it does not affect any extensions that don't use it. The checks you added prevent building say apache module and cli at the same time with some extensions that are available in interactive mode only. With my proposed extension to PHP_EXTENSION the build becomes "smart" in that it links those extensions only with the cli, and not with the other api selected with the build. Edin -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
