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


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]

Reply via email to