Re: [PHP-DEV] Bug fixing and CVS

[Jean-Michel Dault]

Le sam 08/03/2003 à 12:59, Derick Rethans a écrit :
> > Also, right now Mandrake is in deep freeze, so I can only add new
> > patches if they are fully documented and tested. I just can't diff the
> > cvs with the standard version and apply the changes, otherwise the
> > package won't be accepted.
> That's not really our problem, is it?

Nope, it's all mine =)

> > Thanks for taking the time to reply to my (silly?) questions, and
> > specially for the prompt replies. =) When  you come to Montreal, the
> > beer is on me ;-)
> That was not a smart, as I'll be there the 19th to 21st for the 
> PHP Quebec Conference :)

I know, I visit the site every day to see if Damien finally got his mail
and I'm not listed twice, but I still am... The beer offer still stands,
it sure won't be as expensive as the last Linux-Expo in Montreal, where
I invited everyone, paid all drinks and made burgers all night. And
Rasmus won't have to help me carry the food from the store ;-) 

Jean-Michel


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Bug fixing and CVS

[Jean-Michel Dault]

Le sam 08/03/2003 à 10:31, Derick Rethans a écrit :
> > I maintain PHP for Mandrake Linux, and I try to ship a bug-free PHP.
> bug-free doesn't exist :)

I said "I try" ;-) I always try the impossible ;-)

> > That is, if there were some showstopper bugs that were not corrected in
> > 4.3.1, I take the bugfixes from CVS and apply them.
> If you want to do that, then just use the latest stable CVS snapshot...

I would, but the problem is that the snaps are always updated, and the
old files deleted, and my QA requires that the sources be always
available at the same URL. Hmmm.. are they really deleted, or it's just
that the snaps.php.net only shows the recent files?

Also, right now Mandrake is in deep freeze, so I can only add new
patches if they are fully documented and tested. I just can't diff the
cvs with the standard version and apply the changes, otherwise the
package won't be accepted.

> > Is there a better way? Is there a special CVS command to show the diffs
> > on a changelog entry?
> Nope, there is no command for that.
That's what I thought, but I wasn't sure.

> > Would something like bugs.php.net/patches with a list of all closed bugs
> > and their corresponding diffs be thinkable?
> It wont be practicle... it means another extra step for the devs and it 
> will sometimes be forgotten... I don't think it's a good idea as you can 
> always see the CVS commits on the php-cvs@ list anyway.

I understand perfectly.

One last question: is a .phpt file created for every closed bug report,
or is it something that only a couple of developers do?

Thanks for taking the time to reply to my (silly?) questions, and
specially for the prompt replies. =) When  you come to Montreal, the
beer is on me ;-)

Jean-Michel


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Apache2 SAPI

[Jean-Michel Dault]

Le ven 07/03/2003 à 20:29, Ian Holsman a écrit :
> I think it would be in everyone's best interest if apache2handler was 
> introduced in 4.3.X series & probably replace the current apache2filter all 
> together.
> >>>I'm big +1 on this as it can be considered as a FIX..
> >>>Let's just replace the other one with this new one.
> > Just one thing before we make the move: what about the thing with
> > virtual and php re-entrancy? Is that fixed?

> I belive justin fixed that by using the same method the 1.3 handler 
> used (called zend_xyz instead of php_xyz .. i don't have the code in 
> front of me)

Derick, the issue was that virtual() didn't work with apache2handler. Of
course, you could always use file_get_contents, but it creates a couple
of problems (problems when using self-signed ssl certificates, extra log
entries in webserver, only compatible with php 4.3, etc). 

Ian, I just looked at the CVS, it has been fixed two weeks ago, now uses
zend_execute_script instead of php_execute_script, and content-type is
set properly now.

I'll give it a try in the following weeks, I'll let you know of any bugs
or success.

In the meantime, I would not object to put in the 4.3.x series, and even
put it as default, as long as you leave apache2filter as well, so we can
switch from one to the other just by altering the makefile. 

Jean-Michel


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Apache2 SAPI

[Jean-Michel Dault]

Le ven 07/03/2003 à 02:56, Derick Rethans a écrit :
> > >I think it would be in everyone's best interest if apache2handler was 
> > >introduced in 4.3.X series & probably replace the current apache2filter all 
> > >together.
> > I'm big +1 on this as it can be considered as a FIX..
> > Let's just replace the other one with this new one.
> Ok, I'm convinced now too :)

Just one thing before we make the move: what about the thing with
virtual and php re-entrancy? Is that fixed?

Jean-Michel

--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Bug fixing and CVS

[Jean-Michel Dault]

Hello,

I'm not sure this is the right mailing list, but at least it's not about
development _with_ php, it's about development _of_ php ;-)

I maintain PHP for Mandrake Linux, and I try to ship a bug-free PHP.
That is, if there were some showstopper bugs that were not corrected in
4.3.1, I take the bugfixes from CVS and apply them.

My concern is: php-bugs always says "This bug is fixed in CVS", then I
have to look through php-cvs and try to find what changes were made
concerning that specific bug.

Is there a better way? Is there a special CVS command to show the diffs
on a changelog entry?

Would something like bugs.php.net/patches with a list of all closed bugs
and their corresponding diffs be thinkable?

Jean-Michel



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] sapi/embed ?

[Jean-Michel Dault]

Le sam 18/01/2003 à 18:01, Edin Kadribasic a écrit :
> On Fri, 17 Jan 2003, Brian Moon wrote:
> 
> > I just noticed sapi/embed.  Where can I find out more about what this is?  I
> > am hoping it is a sapi that will create a generic library that can be used
> > from any C application.  Is this true?
> 
> Yes it is true. Writing some documentation on how to do it is my TODO 
> list. If you need it right away I can send you some example code.

I would like to have sample code as well, whenever you have a couple of
minutes =)

This looks like a very interesting feature, and I would like to test it,
and make an RPM package for Mandrake with it.

Jean-Michel



--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP building on Linux: A question on configure script!

[Jean-Michel Dault]

Oops.. I forgot the files... Here they are!

Le lun 06/01/2003 à 12:49, Jean-Michel Dault a écrit :
> Le lun 06/01/2003 à 07:24, Ananth Kesari a écrit :
> > What we are looking for is to find out whether or not the current
> > autotool input files of PHP support the ability to produce a spearate
> > phplib.l and the appropriate "main" module - one for Apache 1.3, one for
> > Apache 2.0, one for command line etc. each of which can use the same
> > phplib.l ?
> > 
> > We tried to figure this out on Linux, but it appears that this seems
> > not to be supported. Are we correct in our findings? Or is there really
> > a way of doing the above of having different shared modules?
> 
> It is not supported officially, but there's a way to do it.
> 
> As I promised a couple of days ago, here is a solution that works for
> me, though it's not very pretty. I could of course modify the m4 files,
> but it's left as an exercise to the readers of this list ;-) 
> 
> Here is the procedure:
> 1) Patch the makefile.global and configure script using the
> "shared-patch" I enclosed in this mail. This will compile a shared
> library containing the PHP core, and will patch the CGI and CLI version
> so they use this library.
> 
> 2) do ./configure, with all the options that you want, but do *not* use
> the --with-apache or --with-apxs options. You want to compile first the
> CGI and CLI binaries and the shared library.
> 
> 3) do a make, but do not do a make install yet.
> 
> 4) To compile the Apache 1.3 module, use the enclosed "do1.3" script.
>If your Apache environment is setup correctly, you will have a
>libphp4.so in the sapi/apache directory. This is the Apache DSO that
>you'll need to copy in your Apache 1.3 modules directory.
> 
> 5) To compile the Apache 2.0 module, use the enclosed "do2.0" script.
>If your Apache environment is setup correctly, you will have a 
>mod_php4.so in the sapi/apache2filter/.libs directory. This is the
>Apache 2.0 DSO that you'll need to copy in your Apache 2.0 modules
>directory.
> 
>Please note that to be able to compile both Apache 1.3 and Apache 2.0
>modules, you need two different apxs binaries and two different
>apache include directories. I personnaly use the following dirs:
>Apache 1.3: /usr/sbin/apxs and /usr/include/apache for 1.3 
>Apache 2.0: /usr/sbin/apxs2 and /usr/include/apache2
> 
> 6) Finally, place the libphp_common library in /usr/lib
>mv libphp_common.so libphp_common.so.430
>ln -s libphp_common.so.430 libphp_common
>cp libphp_common* /usr/lib
> 
> 7) Now do a "make install", "make install-cli"
> 
> 8) Finally, you can install sapi/cgi/php to whatever location/name you
>want that is different from the CLI version.
> 
> 9) You'll still need to tweak your httpd.conf to put the required
>LoadModule, AddModule and AddType directives.
> 
> 10) Or better yet, install Mandrake Linux and have it already
> pre-configured ;-)
> 
> 
> Regards,
> 
> Jean-Michel Dault
> Apache/PHP Packager
> Mandrake Linux
> 


diff -urp php-4.3.0.orig/configure php-4.3.0/configure
--- php-4.3.0.orig/configure	2002-12-27 00:50:56.0 -0400
+++ php-4.3.0/configure	2003-01-04 05:52:46.0 -0400
@@ -5681,10 +5681,10 @@ if test "$PHP_SAPI_CLI" != "no"; then
 BUILD_CLI="\$(LIBTOOL) --mode=link \$(CC) -export-dynamic \$(CFLAGS_CLEAN) \$(EXTRA_CFLAGS) \$(EXTRA_LDFLAGS) \$(LDFLAGS) \$(PHP_RPATHS) \$(PHP_GLOBAL_OBJS) \$(PHP_CLI_OBJS) \$(EXTRA_LIBS) \$(ZEND_EXTRA_LIBS) -o \$(SAPI_CLI_PATH)"
 ;;
   *)
-BUILD_CLI="\$(LIBTOOL) --mode=link \$(CC) -export-dynamic \$(CFLAGS_CLEAN) \$(EXTRA_CFLAGS) \$(EXTRA_LDFLAGS) \$(LDFLAGS) \$(PHP_RPATHS) \$(PHP_GLOBAL_OBJS) \$(PHP_CLI_OBJS) \$(EXTRA_LIBS) \$(ZEND_EXTRA_LIBS) -o \$(SAPI_CLI_PATH)"
+BUILD_CLI="\$(LIBTOOL) --mode=link \$(CC) -export-dynamic \$(CFLAGS_CLEAN) \$(EXTRA_CFLAGS) \$(EXTRA_LDFLAGS) \$(LDFLAGS) \$(PHP_RPATHS) -L. -lphp_common \$(PHP_CLI_OBJS) \$(EXTRA_LIBS) \$(ZEND_EXTRA_LIBS) -o \$(SAPI_CLI_PATH)"
 ;;
   esac
-  INSTALL_CLI="\$(mkinstalldirs) \$(INSTALL_ROOT)\$(bindir); \$(INSTALL) -m 0755 \$(SAPI_CLI_PATH) \$(INSTALL_ROOT)\$(bindir)/php"
+  INSTALL_CLI="\$(mkinstalldirs) \$(INSTALL_ROOT)\$(bindir); \$(INSTALL) -m 0755 \$(SAPI_CLI_PATH) \$(INSTALL_ROOT)\$(bindir)/php-cli"
   
   PHP_VAR_SUBST="$PHP_VAR_SUBST BUILD_CLI"
 
@@ -8448,7 +8448,7 @@ EOF
 BUILD_CGI="\$(CC) \$(CFLAGS_CLEAN) \$(EXTRA_CFLAGS) \$(EXTRA_LDFLAGS) \$(LDFLAGS) \$(NATIVE_RPATHS) \$(PHP_GLOBAL_OBJS:.lo=.o) \$(PHP_SAPI_OBJS:.lo=.o) \$(PHP_FRAMEWORKS) \$(EXTRA

Re: [PHP-DEV] PHP building on Linux: A question on configure script!

[Jean-Michel Dault]

Le lun 06/01/2003 à 07:24, Ananth Kesari a écrit :
> What we are looking for is to find out whether or not the current
> autotool input files of PHP support the ability to produce a spearate
> phplib.l and the appropriate "main" module - one for Apache 1.3, one for
> Apache 2.0, one for command line etc. each of which can use the same
> phplib.l ?
> 
> We tried to figure this out on Linux, but it appears that this seems
> not to be supported. Are we correct in our findings? Or is there really
> a way of doing the above of having different shared modules?

It is not supported officially, but there's a way to do it.

As I promised a couple of days ago, here is a solution that works for
me, though it's not very pretty. I could of course modify the m4 files,
but it's left as an exercise to the readers of this list ;-) 

Here is the procedure:
1) Patch the makefile.global and configure script using the
"shared-patch" I enclosed in this mail. This will compile a shared
library containing the PHP core, and will patch the CGI and CLI version
so they use this library.

2) do ./configure, with all the options that you want, but do *not* use
the --with-apache or --with-apxs options. You want to compile first the
CGI and CLI binaries and the shared library.

3) do a make, but do not do a make install yet.

4) To compile the Apache 1.3 module, use the enclosed "do1.3" script.
   If your Apache environment is setup correctly, you will have a
   libphp4.so in the sapi/apache directory. This is the Apache DSO that
   you'll need to copy in your Apache 1.3 modules directory.

5) To compile the Apache 2.0 module, use the enclosed "do2.0" script.
   If your Apache environment is setup correctly, you will have a 
   mod_php4.so in the sapi/apache2filter/.libs directory. This is the
   Apache 2.0 DSO that you'll need to copy in your Apache 2.0 modules
   directory.

   Please note that to be able to compile both Apache 1.3 and Apache 2.0
   modules, you need two different apxs binaries and two different
   apache include directories. I personnaly use the following dirs:
   Apache 1.3: /usr/sbin/apxs and /usr/include/apache for 1.3 
   Apache 2.0: /usr/sbin/apxs2 and /usr/include/apache2

6) Finally, place the libphp_common library in /usr/lib
   mv libphp_common.so libphp_common.so.430
   ln -s libphp_common.so.430 libphp_common
   cp libphp_common* /usr/lib

7) Now do a "make install", "make install-cli"

8) Finally, you can install sapi/cgi/php to whatever location/name you
   want that is different from the CLI version.

9) You'll still need to tweak your httpd.conf to put the required
   LoadModule, AddModule and AddType directives.

10) Or better yet, install Mandrake Linux and have it already
pre-configured ;-)


Regards,

Jean-Michel Dault
Apache/PHP Packager
Mandrake Linux


--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Using PHP for search and replace

[Jean-Michel Dault]

Le lun 06/01/2003 à 06:35, Paul Gregg a écrit :
> > perl -pi -e "s|^;extension=mysql.so|extension=mysql.so|" /etc/php.ini
> > Is there a quick and easy way to do this kind of thing in PHP? Or would
> I was about to say "Ask the RPM makers" until I saw who was asking :-)

Everyone's doing that.. RedHat, SuSe, PLD, Mandrake... so obviously no
RPM guy has ever tried something else ;-)

> How about:
> php -q -r '$lines=file("/etc/php.ini"); $f=fopen("/etc/php.ini", "w"); \
> foreach ($lines as $line) { fwrite($f, preg_replace("/^;extension=mysql.so/",\
> "extension=mysql.so", $line)); } fclose($f);'

I'll try that, thanks!

> I presume perl is no longer a "standard" package installed with either
> redhat or mandrake thus the question ?

No, it's just that it's pretty weird to have a Prereq: perl in a PHP
package. Imagine the irony, you install the best scripting language
(PHP) and you need its competitor (Perl) to be able to use install it
;-)

Jean-Michel


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] CGI and CLI [packaging issues]

[Jean-Michel Dault]

Le sam 04/01/2003 à 18:13, Marcus Börger a écrit :
> What might happen is that CLI becomes widely accepted and scripts
> calling php from shebang lines. Id so your above solution is a bad idea
> and i hope CLI will be...

I'm CC'ing the maintainers of PHP for most distributions of Linux, so we
can all be in sync. For those that don't know the issue, I'll resume it
by saying that with PHP 4.3, there is a new CLI (command-line interface)
that complements the CGI interface. The problem is, both files are named
"php".

Here is the solution that I have been experimenting over the past few
days, and that will be implemented in Mandrake Cooker (and soon 9.1):

- There will be two RPMS: php-cli and php-cgi.
- Both packages will provide php
- Using the "update-alternatives", each package will contain 
 /usr/bin/php as a symlink to the respective binary. This lets us give a
priority to which binary is called for a given symlink. php-cli will be
given priority 20 (higher), php-cgi will be given priority 10 (lower)
- If only one package is installed, /usr/bin/php will link to the right
executable.
- By default, php-cgi will be installed, in order to maintain backwards
compatibility.
- Users will be able to install the CLI using rpm -i php-cli  
- If both packages are installed, php-cli will be called since it's
higher priority.
- All packages that specifically require the command-line interface
(there is none for the moment, but there will be in the future), will
explicitely require php-cli.

This setup means that we don't break the configuration of people that
already have the php CGI interface, while, with one simple command, the
new PHP command-line enthusiasts will be able to have their cake.

This goes with the PHP source approach:
By default, "configure/make/make install" compiles the CGI interface,
and then you have to "make install-cli" to get the CLI.

We just replace the "make install-cli" by "urpmi/apt-get php-cli".

Comments/Questions/Suggestions welcome.

Jean-Michel Dault
PHP/Apache packager
Mandrake Linux


--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] CLI behavior with -q switch

[Jean-Michel Dault]

Several production sytems I manage have a bunch of php scripts, that
were called with php -q using the CGI interface. 

The problem is that the -q switch is still in the CLI for backward
compatibility, but it breaks scripts because it does not change
directories.

I would strongly suggest that the -q switch would imply changing the
working directory to that of the script, unless overriden by -C.

That way, both "php -q" and "php -C -q" (as used in PEAR) would give the
same results with both CGI and CLI.

What do you think?

Jean-Michel Dault
MandrakeSoft


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Using PHP for search and replace

[Jean-Michel Dault]

Hello all,

Currently, both Mandrake and RedHat use the following trick:
perl -pi -e "s|^;extension=mysql.so|extension=mysql.so|" /etc/php.ini

This sucks, because you then need perl to install a PHP extension.
We sure could use sed, but this requires a temporary file, and this
creates some security risks.

Is there a quick and easy way to do this kind of thing in PHP? Or would
this be something that we could integrate?

And I know there's a new solution with the new config-file-scan-dir, but
my question is a general search-and-replace solution.

Any thoughts?

Jean-Michel


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] CGI and CLI (compromise proposal)

[Jean-Michel Dault]

> What might happen is that CLI becomes widely accepted and scripts
> calling php from shebang lines. Id so your above solution is a bad idea
> and i hope CLI will be...

That's a minor problem for me, since the shebang is never standard. Some
people put it in /usr/local, some in /opt, some in /usr/bin, so anyways
you have to modify it.

And with my approach, php will still be called php, with the symbolic
links.

Jean-Michel




-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] CGI and CLI (compromise proposal)

[Jean-Michel Dault]

Le sam 04/01/2003 à 08:15, Marcus Börger a écrit :
> >What happens when a user wants to install *both* php-cli and php-cgi?
> >You cannot have two files with the same name, either in the same RPM, or
> >in two different RPMS... This is not RPM specific, since it will create
> >the same problem with apt, pkgtool, or others.
> But why would he want to? AFAIK Mandrake uses php as an apache module
> and CLI can be used on the commandline. If the user still wants to have CGI
> by a RPM then i would go for naming it to whatever name you like different 
> from
> that of the executable in the CLI RPM. Since RPM can handle all installation
> problems everything is fine then.

Concrete example from our demanding users:

If someone wants to have Apache running PHP, but provide secure PHP in a
chrooted environment for users home directories, they use cgiwrap, thus
php-cgi. But if they use PEAR and php-gtk as well, they'll need the
php-cli.

What you're suggesting is that, when both cgi and cli are installed, the
cli version is called php, and the php-cgi is called something else.

This creates these problems:
- If someone used the cgi version before, it will no longer work, since
the php-cli doesn't write the headers
- If someone used the cgi version in command-line mode, and install the
new cli version, some scripts will be broken, because of the way it does
not change directories before executing the script.

So the default behavior is to have php-cgi, and have some additional
steps to have the CLI. In the source edition, you have to do "make
install-cli", in Mandrake, you'll have to do "rpm -i php-cli".

So what I'll do is the following:
- The standard php binary will be the CGI version, will be called
php-cgi, and have a priority of 20.
- There will be an additional php-cli package, and will have a priority
of 10.
- I will use the "update-alternatives" method to provide a symbolic link
to /usr/bin/php. If only one package is installed, calling PHP will call
the right one. If both are installed, calling php will translate to
php-cgi, which has the highest priority. Users who have both packages
will still be able to chose if they give the proper binary name.

Does this make sense to you? 

Jean-Michel


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Another question on PHP building on Linux.

[Jean-Michel Dault]

Le jeu 02/01/2003 à 10:35, Ananth Kesari a écrit :
> When building for Apache, we don't get, on Linux, the core PHP part as
> a separate binary from the Apache module. This is what the hacked up
> build scripts produced. Thus, instead of having a single core part which
> can be used by Apache 1.3 module, Apache 2.x module, command line
> interface program etc, the whole PHP core is bound statically into each
> of these!

There is a way to do it, but it's not clean enough to put into the PHP
codebase yet. 

> We would like to know whether there is a way to do the way we want it
> to be done by some configure option OR do we need to modify the input
> files to the autotools to enable this?

What I do is build a libphp_common.so with the core PHP code, then I
link the apache DSO, the command-line interface, and cgi version to this
library. This gives a 15K php executable, a 24K apache module, and the
main libphp_common.so is about 1 meg.

I build this in three steps:
1) compile the libphp_common library, php-cli and php-cgi
2) put the SAPI sources somewhere in /usr/src
3) compile Apache 1.3 and Apache 2.0 using the SAPI sources

I haven't ported this to 4.3 yet, since there has been lots of changes
in the makefile and configure scripts, but I'll post it on this list in
a couple of days.

In the meantime, if you're familiar with the RPM environment, you can
download the Mandrake PHP RPM and have a look at the SPEC file.

Jean-Michel


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] CGI and CLI (compromise proposal)

[Jean-Michel Dault]

Hello all,

Sorry to re-activate this topic, but I stumbled into an issue when
packaging PHP 4.3 as an RPM for Mandrake. 

What happens when a user wants to install *both* php-cli and php-cgi? 
You cannot have two files with the same name, either in the same RPM, or
in two different RPMS... This is not RPM specific, since it will create
the same problem with apt, pkgtool, or others.

For Windows, the php.exe and cli/php.exe is good, but on Unix, it would
be bad to have, say, /usr/bin/php and /usr/bin/cli/php!

Here is yet another compromise (for Unix)
1) - name the cli version php-cli
2) - name the cgi version php-cgi
3) - use a wrapper script, symbolic link or another tool (such as
update-alternatives for Linux), to decide which one to call.
4) - tell everyone to change their scripts for the future, so it points
to the right php version.

Step #4 is not that bad, since we always have to change the 1st line of
the scripts anyways... You never know where php is installed, since
DESTDIR is a variable. 

And with the wrapper script, we keep BC, at the expense of a slowdown of
performance.

What do you think?

PS: please answer to me personnaly, as I don't check this mailing list
often.

Regards,

Jean-Michel Dault
Apache/PHP maintainer, Mandrake Linux


Le jeu 19/12/2002 à 10:33, Edin Kadribasic a écrit :
> After having consulted with Andrei, Derick and others on irc here is
> a proposal for a compromise:
> 
> On Unix:
> 
> 1. Both cgi and cli are built as 'php' in their respective sapi
> directories (pretty much as it is today except that cgi gets renamed
> back from php-cgi to just php).
> 2. Make install will *not* install cli if cgi build was selected
> (only cgi gets installed).
> 3. A new install target 'install-cli' is introduced so that make
> install-cli will overwrite whatever is in $(PREFIX)/bin/php.
> 
> On Windows:
> 
> 1. php.exe in the root of distribution is php cgi sapi.
> 2. New cli directory is included with php.exe (cli) in it.
> 
> If this is an acceptable compromise I volunteer to do the changes
> required.
> 
> Edin
> 
> 
> -- 
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, visit: http://www.php.net/unsub.php
> 


--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php