Build system changes

[Russ Allbery]

I'm currently working on converting INN's build system to non-recursive
Automake.  This is something I've wanted to do for years, although the
problem that got me to finally start is
https://github.com/InterNetNews/inn/issues/206.

There are a few things that INN currently does in its build system which
are sort of easy (or at least possible) to do with hand-rolled Makefiles,
but which don't entirely fit Automake's model.  We could do some extra
work to reproduce them, but I think changing how the build system works
minorly to be more in-line with Automake's expectations may make things
more maintainable in the long run.

These changes (and indeed all of the Automake work) would only be in the
main branch, not in the 2.6 release branch.

I haven't found everything, but a few things for people to think about to
start with:

1. The pluggable storage, overview, and history mechanism, where we
   generate build rules at build time, is possible with Automake but it
   would add a fair amount of complexity.  I feel like it's a very
   uncommon operation to add a new storage, overview, or history backend,
   and if one is doing this, modifying the top-level Makefile.am is the
   least part of that work, so we should drop that level of dynamic
   generation.  However, what would be useful is to not build backends
   whose dependencies aren't available.  (For example, we shouldn't build
   ovdb if we don't have BerkeleyDB, and then attempting to use it should
   be an error.)

   Automake provides conditional compilation that would let us do exactly
   this, in combination with some preprocessor logic in files like
   ovmethods.c.  My inclination is to go in that direction: the build
   rules will always be present in the top-level Makefile.am, but
   (eventually, probably not in the first PR) conditional on whether we
   have the prerequisites to build that backend.

2. I'd like to look at using that same conditional compilation approach
   for the embedded Perl and Python support.  We could then drop the
   preprocessor guards on those files, only guard the invocations of the
   functions they export (and possibly stub them out with a clever header
   file to reduce the amount of conditional compilation), and then choose
   whether to link them into the binaries based on Automake conditionals.

   Note that, to support using different compilation flags for those
   files, they'll actually be built as libtool convenience libraries when
   using an Automake build system.  (This should be invisible to anyone
   building INN.)

3. There are profiling rules scattered around the INN build system, but
   I've never used them and I'm not sure they work as-is.  I also don't
   know how to convert them to Automake.  I currently intend to drop
   them.

4. Having the man pages and POD source in different directories makes it
   hard to write suffix rules to convert POD to man pages.  I'd like to
   unify the man and pod directories so that the man pages are generated
   beside the POD source for that page, since that will avoid a bunch of
   tedious copy-paste rules for each individual page.

5. I'm inclined to move the POD source for files like INSTALL, NEWS,
   and README to live alongside those files (so INSTALL.pod, NEWS.pod,
   and README.pod).  This doesn't really make much difference for the
   build system, but it will provide nicer rendering on GitHub.  Might
   make sense to do something similar with the files in the top level of
   doc.  That would essentially empty out the doc/pod directory in favor
   of moving the POD source next to the generated file.

6. As previously discussed, the MANIFEST file doesn't do anything under
   Automake (it has its own mechanism for tracking what goes into a
   distribution), so I'd like to drop it.

7. The easy way to implement the special ownership and permission rules
   for some INN files is to install them with regular permissions and then
   fix the permissions afterwards with install-exec-hook.  That does mean
   there will be a window where the permissions will be wrong.  Does that
   seem okay?

I haven't yet figured out how to support the -S .OLD option to install.
Not sure yet how hard that will be.  I'm planning on keeping the site
directory as-is and invoking it via recursive make, at least for now.

-- 
Russ Allbery (eagle at eyrie.org)             <https://www.eyrie.org/~eagle/>

    Please send questions to the list rather than mailing me directly.
     <https://www.eyrie.org/~eagle/faqs/questions.html> explains why.