Date: Sun, 29 Jun 1997 12:58:18 -0600 (MDT)
From: Marc Slemko <marcs@znep.com>
To: new-httpd@apache.org
Subject: Re: Source reorganisation
In-Reply-To: <Pine.LNX.3.95.970629154318.8188A-100000@aardvark.ukweb.com>
Message-ID: <Pine.BSF.3.95.970629125348.19339B-100000@alive.znep.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@apache.org

On Sun, 29 Jun 1997, Paul Sutton wrote:

> There has been some discussion about re-organising the source files. To
> give us something concrete to talk about, and possibly implement, I've
> attempted to do this. I've also implemented some of the requested features
> such as making it easier to install new (third-party) modules, and to
> allow modules to influence the configuration process.
> 
> The system implements the following changes:
> 
>   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.

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

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

> Besides moving the source files around, the main changes for this are to
> Configure itself. Since it does involve moving most of the source files, I
> cannot really send a working patch for the whole change. But I could send
> a patch for Configure if this seems like a good idea.
> 
> I think it makes the Apache source tree easier to manage, allows us to
> start on OS abstraction, makes it easier to provide additonal modules and
> provides a better level of organisation to the source. It should also have
> _no_ effect on the stabilty of Apache itself, since there are no code
> changes.

I'm thinking this is best left until after 1.3.  Right now, and in the
forseeable future, it is nice to be able to do a diff between HEAD and
1.2.0 to see all the things that have come in, find the bogus ones, etc.