Re: always building cgi...

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