Re: Source reorganisation

[Paul Sutton <pa...@ukweb.com>]

On Sun, 29 Jun 1997, Marc Slemko wrote:
> On Sun, 29 Jun 1997, Paul Sutton wrote:
> >   1. Source code re-organisation, with the "core" source and header files
> >      moved into /src/core, os-specific files in /src/os/OSNAME, modules
> >      in /src/modules/SOMETHING and support in /src/support. OS-specific
> >      source and header files can be added.
> 
> What is an OS?  Is Unix an OS or is FreeBSD an OS?  I don't see the need
> or desire for seperate subdirectories per Unix variety, as someone has
> suggested sometime.  We just don't have the volume to make it worthwhile.

Umm, I can see advantages to treating these as different OSes. But my
assumption was that the are only three OSes at the moment: win32, unix and
emx. FreeBSD, Linux, etc are 'variants' of the unix OS, while winnt and
win95 are variants of win32. 

> >   2. Modules are easier to add and better organised. They can be placed
> >      in _any_ subdirectory of /src/modules, and a suitable Makefile will
> >      be auto-created if necessary. For example, all the default modules
> >      could go into /src/modules/standard, all the auth modules into
> >      /src/modules/auth, etc. Third-party modules can be dropped into any
> >      new or existing directory. 
> 
> Sounds ok, but if you are defining "default modules" as those compiled in
> by default, I'm not sure that distinction is worthwhile.  If you mean
> those distributed by default, sure.

The arrangement of the modules is arbitrary - the new Configure can handle
any modules in any directories. It will auto-create Makefiles as necessary
in directories under /src/modules. So the paths above a just examples. For
my testing I put all the modules distributed with Apache in
/src/modules/standard, except for the authentication modules which went
into /src/modules/auth. The auth modules are a functionally distint set of
modules, but of course they could all be put into a single directory as
well. 

This scheme would also let us distribute "experimental" modules more
clearly marked as such, by putting them in /src/modules/experimental. 

> >   3. Modules can contain additional information used by "Configure". For
> >      example, they can request extra libraries or add extra CFLAGS. This
> >      can be specified either within the C-file itself (as a specially
> >      formatted comment), or in a separted "module definition file", which
> >      could be distributed with binary (.o or .a) modules.
> 
> Sounds good.  Seperate module definition file would be best.  Could even
> make a standard format that includes author, description, etc.

Yes, that is a good idea. The format can of course be adjusted, but a
typical module definition might look like this: 

Name:        dbm_auth_module
Author:      Apache Group
Description: Basic authentication with passwords stored DBM file
StartConfigure
  LIBS=$LIBS $DBMLIB
EndConfigure

The Name: gives the module structure name (needed for Configure and
currently given in Configuration), the next two lines are comments, and
the StartConfigure...EndConfigure block is executed by Configure after it
has determined the OS specific settings. I would prefer not to have shell
commands in the definition, but modules need to be able to influence the
configuration in a generic way (e.g. mod_status needs to check the value
of the STATUS rule). 

This whole block can be put into a separate file (i.e. 
mod_auth_dbm.module), or added into the source code inside a comment). 

//pcs