Message-Id: <199706291917.OAA05947@sierra.zyzzyva.com>
To: new-httpd@apache.org
Subject: Re: Source reorganisation 
In-reply-to: marcs's message of Sun, 29 Jun 1997 12:58:18 -0600.
         <Pine.BSF.3.95.970629125348.19339B-100000@alive.znep.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sun, 29 Jun 1997 14:17:17 -0500
From: Randy Terbush <randy@zyzzyva.com>
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.

While I agree that this could get rather large, conf.h could 
benefit from splitting out the "OS" specific items in this file. 
Under that model, I think that there could be specifics for bsd44, 
hpux, win32, os2, etc.


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

I understand Paul to mean those distributed by default. The other 
directory would be a convenient place to put other "third party" 
modules like mod_perl, mod_php etc.


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

I think that it is foolish to hold these types of changes on the 
off chance that 1.2.x will change. With some luck, 1.2.1 could be 
the final 1.2 release. I would vote to include these changes now.