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