[OpenAFS-devel] Future direction for Autoconf macro handling in OpenAFS

[Russ Allbery]

Jeffrey Hutzelman <jhutz@cmu.edu> writes:
> Russ Allbery <rra@stanford.edu> wrote:

>> I think it's confusing to put things into acinclude.m4 that are only
>> used by configure.in.  This is unlike the way nearly every other free
>> software program using Autoconf uses its configure.ac file and is
>> unnecessarily confusing for contributors.

> On the contrary, nearly every other free software program using Autoconf
> doesn't use acinclude.m4 *at all*.  The ones that do are usually using it
> as the transitional mechanism it was intended to be, rather than as a way
> of abstracting out common "main" code between multiple configure scripts.

Right, that's my point.  Therefore, given that the second configure script
needs only a minimum amount of code outside the kernel probes and sysname
detection, minimizing the use of acinclude.m4 so that things are in
configure.ac where people expect them to be makes sense to me.

However...

> This probably actually includes lots of command-line options.  As long
> as the information about what command-line options exist is consolidated
> in one place, I think I'm in favor of moving the details into separate
> macros in appropriate src/cf/*.m4 files, in the process bringing an
> option together with the bits that implement its effect.

...this we can certainly agree on, so we should probably just start here
and then worry about what file to put the results into after we've done
this part.  So I think I'd rather defer the rest of this discussion until
we know what the remnants left in acinclude.m4 will look like, since it
may be that the right organization will be obvious to everyone at that
point.

> As long as we're cleaning things up, then...

> We have four or five more README files than we should (README.GIT and
> README.WARNINGS can and should be folded into README.DEVEL, which
> possibly should be moved to the web site.

I like keeping such things with the package, but I like the idea of
combining them all.  I'd then tend to call the resulting file HACKING,
which is the name for that file that I've seen in use elsewhere, although
I don't feel strong about that.

> README-WINDOWS can and should be folded into README.

Agreed.

> README.PTHREADED_UBIK does not belong in the top level).

Also agreed.

> We have one more INSTALL file than we should.  The generic instructions
> are not only fairly old, but also contain information that is
> irrelevant, just plain wrong, or even actively harmful.  For example,
> the discussion of system types is pretty much completely wrong; anything
> we do that is system-type-dependent depends on the AFS systype, not the
> configure one. The README file already contains much better installation
> instructions; we should punt the generic GNU one.

Yeah, I hate the generic GNU installation instruction document.  It's
practically never useful or accurate.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>