Re: [PHP-DEV] always building cgi...

2001-04-17 Thread Andi Gutmans

Well I have been abroad and been reading Emails very slowly via 
international calls so I might have missed a few (no need for the sarcasm).
What I describe is the situation I would like to see. I will try and catch 
up will the zillions of Email I have and see why this can't be achieved.

Andi

At 04:01 PM 4/15/2001 +0200, Sascha Schumann wrote:
> > All it really requires is compiling cgi_main.c with the same flags and
> > linking it to the libphp4.la
>
> If you had read the emails, you would have noticed the
> problem behind that thought.
>
> - Sascha Experience IRCG
>   http://schumann.cx/http://schumann.cx/ircg


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] always building cgi...

2001-04-15 Thread Sascha Schumann

> All it really requires is compiling cgi_main.c with the same flags and
> linking it to the libphp4.la

If you had read the emails, you would have noticed the
problem behind that thought.

- Sascha Experience IRCG
  http://schumann.cx/http://schumann.cx/ircg


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] always building cgi...

2001-04-15 Thread Andi Gutmans

I think having a CGI (command line) version of PHP built in any case is a 
very useful thing. I would just make it build with the same options as the 
rest. So if we build a non-threadsafe Apache 1.3.x module I would also 
build a non-threadsafe command line version (just in case the person feels 
like using it).  If you build a thread-safe version then we can build a 
thread-safe command line version.
All it really requires is compiling cgi_main.c with the same flags and 
linking it to the libphp4.la
I just think it's a useful thing to have. I wouldn't complicate this into 
allowing people to build both Apache & thttpd versions with the same "make" 
command. I think people are really interested in just having a command line 
& web server version.
Andi

At 02:58 PM 4/13/2001 +0300, Boian Bonev wrote:

> > > With some more minor restructuring, we can then let people build _all_
> > > sapi modules in one go if they like.
> > Without careful consideration, I would not say that it would
> > require only minor restructuring.  If we would implement that
> > change, it would have a direct effect upon the installation
> > procedure of PHP.  That is not a problem with online
> > documentation, but what about printed manuals and the dozens
> > of books on PHP?  I'd be very hesitant to change anything
> > here which would render those descriptions invalid.
>
>if a backwards compatible configure command line is kept valid why not? if
>the sapi module(s) to install becomes a list of --with-somesapi it would not
>break neighter descriptions nor saved built scripts.
>
> > On the implementation side, I'm not convinced of the
> > usefulness of such a change.  The way libphp4.la is built
> > directly depends upon the chosen SAPI module (thread-safety,
> > shared/static).  As of today, there are only a few possible
> > combinations.  From day-to-day experience, I have yet to see
> > an installation where web-servers run parallelly (and which
> > use PHP/require the same build options).
>
>there are two ways of building libphp4.la - thread safe and not thread safe.
>let us say libphp4.la and libphp4ts.la. the rest is just a linker option or
>am i missing something? i think the idea to separate the sapi stuff from the
>rest of php is not that bad - you build php once (or twice for TS) and then
>link to sapi modules at will.
>
>b.
>
>
>--
>PHP Development Mailing List 
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>To contact the list administrators, e-mail: [EMAIL PROTECTED]


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] always building cgi...

2001-04-13 Thread Boian Bonev


> > With some more minor restructuring, we can then let people build _all_
> > sapi modules in one go if they like.
> Without careful consideration, I would not say that it would
> require only minor restructuring.  If we would implement that
> change, it would have a direct effect upon the installation
> procedure of PHP.  That is not a problem with online
> documentation, but what about printed manuals and the dozens
> of books on PHP?  I'd be very hesitant to change anything
> here which would render those descriptions invalid.

if a backwards compatible configure command line is kept valid why not? if
the sapi module(s) to install becomes a list of --with-somesapi it would not
break neighter descriptions nor saved built scripts.

> On the implementation side, I'm not convinced of the
> usefulness of such a change.  The way libphp4.la is built
> directly depends upon the chosen SAPI module (thread-safety,
> shared/static).  As of today, there are only a few possible
> combinations.  From day-to-day experience, I have yet to see
> an installation where web-servers run parallelly (and which
> use PHP/require the same build options).

there are two ways of building libphp4.la - thread safe and not thread safe.
let us say libphp4.la and libphp4ts.la. the rest is just a linker option or
am i missing something? i think the idea to separate the sapi stuff from the
rest of php is not that bad - you build php once (or twice for TS) and then
link to sapi modules at will.

b.


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] always building cgi...

2001-04-13 Thread Anil Madhavapeddy

Sascha Schumann wrote:

> combinations.  From day-to-day experience, I have yet to
> see an installation where web-servers run parallelly
> (and which use PHP/require the same build options).

This is true.  Just one SAPI module + CGI would be exceedingly useful.
Keeping them in sync wrt modules compiled in is a pain.

Anil


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] always building cgi...

2001-04-13 Thread Stig Sæther Bakken

[Sascha Schumann <[EMAIL PROTECTED]>]
> > Okay, what about making libphp4.la contain everything but libsapi.la,
> > and make a new final target including libsapi.la called
> > libphp4_xxx.la, where xxx is the sapi module used.
> >
> > With some more minor restructuring, we can then let people build _all_
> > sapi modules in one go if they like.
> 
> [my internet link died yesterday and I forgot to resend this]
> 
> Without careful consideration, I would not say that it would
> require only minor restructuring.  If we would implement that
> change, it would have a direct effect upon the installation
> procedure of PHP.  That is not a problem with online
> documentation, but what about printed manuals and the dozens
> of books on PHP?  I'd be very hesitant to change anything
> here which would render those descriptions invalid.
> 
> On the implementation side, I'm not convinced of the
> usefulness of such a change.  The way libphp4.la is built
> directly depends upon the chosen SAPI module (thread-safety,
> shared/static).  As of today, there are only a few possible
> combinations.  From day-to-day experience, I have yet to see
> an installation where web-servers run parallelly (and which
> use PHP/require the same build options).

It would probably only be useful to distribution builders.  However,
the point is having the CGI and something else at the same time.  It
seems this is leading us towards a 4.1 release.

 - Stig

-- 
  Stig Sæther Bakken <[EMAIL PROTECTED]>
  Fast Search & Transfer ASA, Trondheim, Norway

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] always building cgi...

2001-04-12 Thread Colin Viebrock

> On the implementation side, I'm not convinced of the
> usefulness of such a change.  The way libphp4.la is built
> directly depends upon the chosen SAPI module (thread-safety,
> shared/static).  As of today, there are only a few possible
> combinations.  From day-to-day experience, I have yet to see
> an installation where web-servers run parallelly (and which
> use PHP/require the same build options).

FWIW, 99% of the time when I build PHP I build the Apache module and the CGI
at the same time with the same ./configure scripts.  The module is for the
website and the CGI is for cron scripts, inetd daemons, etc..

I am very much in favour of a way to compile both at once.

- Colin


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] always building cgi...

2001-04-12 Thread Edin Kadribasic

This would certainly make my life easier. By now I have a few dozen scripts
that begin with #!/usr/bin/php -q

So building command line interpreter (cgi sapi) and optionally one other
sapi module in one go would be nice indeed.

Edin

> If there was some way of building the cgi with any sapi, that would be
nice.
> PHP as a cgi is becoming more of a utility than a cgi.
>
> Is there a way to accomplish this without changing the user compile
interface much?
>
> -Jason
>
> - Original Message -
> From: "Sascha Schumann" <[EMAIL PROTECTED]>
> To: "Stig Sæther Bakken" <[EMAIL PROTECTED]>
> Cc: "Stig Sæther Bakken" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> Sent: Thursday, April 12, 2001 8:54 PM
> Subject: Re: [PHP-DEV] always building cgi...
>
>
> > > Okay, what about making libphp4.la contain everything but libsapi.la,
> > > and make a new final target including libsapi.la called
> > > libphp4_xxx.la, where xxx is the sapi module used.
> > >
> > > With some more minor restructuring, we can then let people build _all_
> > > sapi modules in one go if they like.
> >
> > [my internet link died yesterday and I forgot to resend this]
> >
> > Without careful consideration, I would not say that it would
> > require only minor restructuring.  If we would implement that
> > change, it would have a direct effect upon the installation
> > procedure of PHP.  That is not a problem with online
> > documentation, but what about printed manuals and the dozens
> > of books on PHP?  I'd be very hesitant to change anything
> > here which would render those descriptions invalid.
> >
> > On the implementation side, I'm not convinced of the
> > usefulness of such a change.  The way libphp4.la is built
> > directly depends upon the chosen SAPI module (thread-safety,
> > shared/static).  As of today, there are only a few possible
> > combinations.  From day-to-day experience, I have yet to see
> > an installation where web-servers run parallelly (and which
> > use PHP/require the same build options).
> >
> > - Sascha Experience IRCG
> >   http://schumann.cx/http://schumann.cx/ircg
> >
> >
> > --
> > 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]
> >
>
>
> --
> 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]
>
>


-- 
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]




Re: [PHP-DEV] always building cgi...

2001-04-12 Thread Jason Greene

If there was some way of building the cgi with any sapi, that would be nice.
PHP as a cgi is becoming more of a utility than a cgi.

Is there a way to accomplish this without changing the user compile interface much?

-Jason

- Original Message -
From: "Sascha Schumann" <[EMAIL PROTECTED]>
To: "Stig Sæther Bakken" <[EMAIL PROTECTED]>
Cc: "Stig Sæther Bakken" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Thursday, April 12, 2001 8:54 PM
Subject: Re: [PHP-DEV] always building cgi...


> > Okay, what about making libphp4.la contain everything but libsapi.la,
> > and make a new final target including libsapi.la called
> > libphp4_xxx.la, where xxx is the sapi module used.
> >
> > With some more minor restructuring, we can then let people build _all_
> > sapi modules in one go if they like.
>
> [my internet link died yesterday and I forgot to resend this]
>
> Without careful consideration, I would not say that it would
> require only minor restructuring.  If we would implement that
> change, it would have a direct effect upon the installation
> procedure of PHP.  That is not a problem with online
> documentation, but what about printed manuals and the dozens
> of books on PHP?  I'd be very hesitant to change anything
> here which would render those descriptions invalid.
>
> On the implementation side, I'm not convinced of the
> usefulness of such a change.  The way libphp4.la is built
> directly depends upon the chosen SAPI module (thread-safety,
> shared/static).  As of today, there are only a few possible
> combinations.  From day-to-day experience, I have yet to see
> an installation where web-servers run parallelly (and which
> use PHP/require the same build options).
>
> - Sascha Experience IRCG
>   http://schumann.cx/http://schumann.cx/ircg
>
>
> --
> 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]
>


-- 
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]




RE: [PHP-DEV] always building cgi...

2001-04-12 Thread Sean R. Bright


> -Original Message-
> From: Sascha Schumann [mailto:[EMAIL PROTECTED]]
>
> documentation, but what about printed manuals and the dozens
> of books on PHP?  I'd be very hesitant to change anything

http://www.amazon.com/exec/obidos/ASIN/1861002963

I think I smell a second edition ;)

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] always building cgi...

2001-04-12 Thread Sascha Schumann

> Okay, what about making libphp4.la contain everything but libsapi.la,
> and make a new final target including libsapi.la called
> libphp4_xxx.la, where xxx is the sapi module used.
>
> With some more minor restructuring, we can then let people build _all_
> sapi modules in one go if they like.

[my internet link died yesterday and I forgot to resend this]

Without careful consideration, I would not say that it would
require only minor restructuring.  If we would implement that
change, it would have a direct effect upon the installation
procedure of PHP.  That is not a problem with online
documentation, but what about printed manuals and the dozens
of books on PHP?  I'd be very hesitant to change anything
here which would render those descriptions invalid.

On the implementation side, I'm not convinced of the
usefulness of such a change.  The way libphp4.la is built
directly depends upon the chosen SAPI module (thread-safety,
shared/static).  As of today, there are only a few possible
combinations.  From day-to-day experience, I have yet to see
an installation where web-servers run parallelly (and which
use PHP/require the same build options).

- Sascha Experience IRCG
  http://schumann.cx/http://schumann.cx/ircg


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] always building cgi...

2001-04-11 Thread Jason Greene

i like the sound of that

-jason
- Original Message -
From: "Stig Sæther Bakken" <[EMAIL PROTECTED]>
To: "Sascha Schumann" <[EMAIL PROTECTED]>
Cc: "Stig Sæther Bakken" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Wednesday, April 11, 2001 1:43 PM
Subject: Re: [PHP-DEV] always building cgi...


> [Sascha Schumann <[EMAIL PROTECTED]>]
> > > Sascha, what symbols can sneak in to break linking?  A few examples I
> > > can test with would be nice.
> >
> > As other people on this list have mentioned, building
> > --with-apxs illustrates the breakage.
> >
> > The chosen SAPI module (i.e. sapi/apache/libsapi.la) is part
> > of libphp4.la.  Usually, the SAPI module contains calls to
> > server-specific APIs which are resolved upon loading the SAPI
> > module into the web-server.  Those external symbols cannot be
> > found (of course) during creating the CGI which is built
> > using libphp4.la.
>
> Okay, what about making libphp4.la contain everything but libsapi.la,
> and make a new final target including libsapi.la called
> libphp4_xxx.la, where xxx is the sapi module used.
>
> With some more minor restructuring, we can then let people build _all_
> sapi modules in one go if they like.
>
>  - Stig
>
> --
>   Stig Sæther Bakken <[EMAIL PROTECTED]>
>   Fast Search & Transfer ASA, Trondheim, Norway
>
> --
> 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]
>


-- 
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]




Re: [PHP-DEV] always building cgi...

2001-04-11 Thread Stig Sæther Bakken

[Sascha Schumann <[EMAIL PROTECTED]>]
> > Sascha, what symbols can sneak in to break linking?  A few examples I
> > can test with would be nice.
> 
> As other people on this list have mentioned, building
> --with-apxs illustrates the breakage.
> 
> The chosen SAPI module (i.e. sapi/apache/libsapi.la) is part
> of libphp4.la.  Usually, the SAPI module contains calls to
> server-specific APIs which are resolved upon loading the SAPI
> module into the web-server.  Those external symbols cannot be
> found (of course) during creating the CGI which is built
> using libphp4.la.

Okay, what about making libphp4.la contain everything but libsapi.la,
and make a new final target including libsapi.la called
libphp4_xxx.la, where xxx is the sapi module used.

With some more minor restructuring, we can then let people build _all_
sapi modules in one go if they like.

 - Stig

-- 
  Stig Sæther Bakken <[EMAIL PROTECTED]>
  Fast Search & Transfer ASA, Trondheim, Norway

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] always building cgi...

2001-04-10 Thread Sascha Schumann

> Sascha, what symbols can sneak in to break linking?  A few examples I
> can test with would be nice.

As other people on this list have mentioned, building
--with-apxs illustrates the breakage.

The chosen SAPI module (i.e. sapi/apache/libsapi.la) is part
of libphp4.la.  Usually, the SAPI module contains calls to
server-specific APIs which are resolved upon loading the SAPI
module into the web-server.  Those external symbols cannot be
found (of course) during creating the CGI which is built
using libphp4.la.

- Sascha Experience IRCG
  http://schumann.cx/http://schumann.cx/ircg


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]