[OpenAFS-devel] Re: autoconf

[Nathan Neulinger]

Derrick J Brashear wrote:
> 
> On 12 Dec 2000, Russ Allbery wrote:
> 
> > Derrick J Brashear <shadow@dementia.org> writes:
> >
> > > We wanted to get something out there for people to play with. Autoconf
> > > involves breaking the whole world for the duration of the work,
> > > basically.
> >
> > Hm.  It might not *have* to.  We managed to avoid that when
> > autoconfiscating INN, for example.  Sometimes you can use autoconf to
> > generate a file that defines all the stuff that the legacy code expects,
> > and then slowly remove the legacy definitions as they're stripped out of
> > the rest of the code.
> >
> > But it depends on how the code's structured and how it uses portability
> > information and I haven't done a thorough inspection of OpenAFS yet to
> > figure out a good approach.
> 
> Well, nothing in AFS is based on feature definitions, it's all based on
> systype stuff. The logical way to handle non-kernel stuff is to work on
> feature-based definitions, which is going to make the old build system
> break as things get converted unless 2 sets of portability information are
> kept and we switch to the new one when we get all the feature stuff done.
> 
> It seems that it would be less time consuming to just have 2 trees (a
> stable tree and a devel tree) and break the devel tree for a few weeks
> while autoconfiscation happens. My plan was to work on it or find others
> to do so, imminently.

Why not start out by getting the following autoconf capabilities:

	determine the afs systype from the host type determined by autoconf
	build in separate source tree - using the autoconf linking of files
instead of the pre-setup way we have now.
	generate a config.h that stuff can start including.

that should be simple enough

Once you have the above, which shouldn't be all that difficult to
accomplish, you can start adding all sorts of other tests, etc. and
individual components of openafs can start using them as people submit
patches. For example, initially, it would be easy enough to take all the
proto Makefiles and make then into protomakefile.in's for each platform.
You could then start stripping out hardwired stuff in that makefile as
you had time. 

I'd think that a short period of time would be sufficient to do the
initial 'add autoconf support', then the rest 'make it use autoconf for
as much as possible' can be done gradually.

-- Nathan

------------------------------------------------------------
Nathan Neulinger                       EMail:  nneul@umr.edu
University of Missouri - Rolla         Phone: (573) 341-4841
CIS - Systems Programming                Fax: (573) 341-4216