httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Sutton <p...@ukweb.com>
Subject Re: Module install steps
Date Sun, 26 Oct 1997 16:10:31 GMT
On Sat, 25 Oct 1997, Rasmus Lerdorf wrote:
> That's a whole lot better than all the crap you had to do for PHP2.  I'd

Glad to hear it.

> like to cut it even further though.  Would it be an idea to have Configure
> check modules/extra for the presence of any modules and automatically add
> these without having to be explicitly told to do so in the Configuration
> file?  I mean, if people go and put a module in there, chances are they
> want it compiled in.

The requirement for people to add their own AddModule lines is a pain. I
think it is now a lot simpler than it was (because they don't need to
enter the C-language structure name, just a filename, which is much more
obvious). 

However I'm not sure whether you could eliminate this stage. One thing I
though of (while designing this stuff) was to create another directory,
say modules/autoadd, which contained modules which _always_ got added to
the configuration, without needing an AddModule. The core module could go
in there, and it could be used by third-party module authors to eliminate
the AddModule adding step. A big README file in the directory would
explain that users can remove modules by moving them to another directory
(say modules/extra). One possible problem with this is module ordering -
the core module needs to come before all others, while third-party modules
would come at the end. This could be done by an extra line in the .module
or CONFIG_START/END sections.

Or give Configure an additional option, say "--add-module", which would
add the AddModule line to Configure, so your installer could call

  ".../src/Configure --add-module modules/extra/mod_php.module"

and get it done behind the scenes for the user. 

> The second hand-edit might be eliminated by having a .module directive
> that adds something to the internal mime type table.  We already have a
> bunch of magic internal mime types.

This I'm not so sure about. Most people will have already installed Apache
bfore they merge in PHP (I guess), so any edits you make to
conf/mime.types wouldn't get into the live server anyway. People also
might want to only enable PHP parsing in certain virtual hosts or
<Directory> sections, so it is best if they chose where to put the
AddType. 

//pcs



Mime
View raw message