Rewriting INN's build system

Julien ÉLIE julien at
Sun Aug 21 19:21:51 UTC 2011

Hi Russ,

> I'd therefore like to propose pretty radically overhauling the INN build
> system to look like my other projects: non-recursive Automake, separate
> portable and util directories, renaming some things to match rra-c-util's
> naming conventions, always using libtool in the build, and so forth.  I
> think this would make the build system both more robust and more like many
> other free software projects, and will also make it easier to share code
> with rra-c-util.

All the points your are mentioning seem to be useful improvements to our 
current build system.  As you say, we're now in 2011, and INN would 
largely benefit from using the current state of art regarding its build 

I believe going into that direction is a good idea.

> * Non-recursive make gives us a correct global dependency tree, which
>   means everything is rebuilt properly, every time.  No more editing a
>   file in lib and then running make in innd and having nothing change
>   because the innd Makefile doesn't realize that the file modification
>   means libinn needs to be rebuilt.

We will no longer be puzzled by an unexpected behaviour in the main code 
or the test suite because of a dependency that has not properly been 

> * Proper support for builds outside of the source tree or with a read-only
>   source tree.

Ah, I bet that is the reason for the built-in SOURCE and BUILD variables 
in runtests.  I did not know well how to set them in the Makefile, 
because they appear to be the same for our current build system (the 
test suite is run from the SOURCE tree).

> * We would stop using libtool in a weird conditional way, which is
>   currently causing problems because that's never tested and tends to
>   break.  (Updating libtool right now causes errors from sed in
>   configure.)

Yes, that's annoying.

> * Could stop manually importing libtool and config.{guess,sub} and just
>   install them in the tree using the autogen script, which means carrying
>   around fewer external files in the source tree.

 From where would autogen take these files (especially when network is 

> * Generate man pages and text documentation from POD in autogen rather
>   than as part of the build with Makefiles.  This is needed for proper
>   support of building outside the source tree.  It's a bit more tedious if
>   only one file has changed, but I do this now with other projects and I
>   think it's cleaner.

Couldn't a "make doc" command be also available, though not triggered 
off by "make" (but probably triggered off by "make all")?

> * Eliminate MANIFEST and instead use Automake's make dist support.  This
>   means fewer support scripts and idiosyncratic ways of doing things, but
>   it does mean we won't have the file documenting what every file is for
>   (although I'm not sure how really useful that is).

We could also keep MANIFEST, which could be an interesting thing to have 
for an overview of the whole distributed files.  The only difference 
would be that the MANIFEST file is no longer used for the generation of 
snapshots or releases.  We could imagine to update it when doing a 
release.  Just generate the tar ball, and check that every file is 
mentioned in MANIFEST.  Update it, if needed, and regenerate the tar 
ball.  It does not take much time.
Well, that's just a suggestion.

> * We'd lose the backup .OLD support for updated binaries and similar files
>   on make upgrade.  I'm not sure what to think about this.  We could try
>   to hack it into Automake, I suppose, but it's definitely a bunch of
>   extra complexity.

A nice thing is that it will fix an "issue" with the -perm flag of 
inncheck :-)

% inncheck -perm
/home/news/bin/rnews.libexec:0: ERROR: illegal file `c7unbatch.OLD' in 
directory (it may be a valid backup if it ends with '.OLD')

On a side note, we have other subtleties in install-sh.  According to 
the beginning of the script:

# This file has been modified from the standard libtool version by
# adding the -B option to request saving of the original file
# (if install is overwriting an existing file).  -B takes an argument:
# the suffix to use.
# INN invokes this script as "install-sh -B .OLD".  Also modified
# to use cp -p instead of just cp to install programs when invoked as
# install -c.
# It also handles .exe extensions, for Cygwin portability, and prevents
# existing directories from being chown'ed.
# Search for comments below containing "INN".

So dropping the .OLD backup generates other drawbacks.
Anyway, re-adding support for all these local change is usually quick. 
All the parts that need being changed are properly marked up in 
install-sh and

Of course, it would be best not to have to do all these changes.  But if 
we cannot avoid them...

> Could we just tell people to make a backup of their install tree
> before running make upgrade?  How much do people actually use this?

It once was useful when I ran by mistake "make install" instead of "make 
update" :-)
Hmm...  Maybe we could just add a check, when running "make install" 
that inn.conf is not already installed.  If the file is present, we 
could just abort, saying that inn.conf should be removed before 
proceeding, or ask "Are you sure?"

Otherwise, I do not see obvious uses for the .OLD backup.

> * Non-recursive make means that you can't just run make in the directory
>   you're working in.  make only works at the top level.

Can't a Makefile running "$(top)/make" be present in a subdirectory?

(It may not be an Automake best practice so perhaps such a Makefile 
should not be created.)

> * We'd lose the modular plug-in build system for history, storage, and
>   overview methods.  Or, rather, we wouldn't have to, but I'd not bother
>   to convert that and would replace it with straightforward Automake rules
>   for the in-tree methods, since I don't think the complexity is worth it.
>   It's a really neat idea, but I don't think there are a bunch of
>   alternative backend developers out there who are actively using the
>   ability to drop their code into INN's tree but don't want us to just
>   check it into CURRENT.

Or if there are, maybe they will add the extra-complexity themselves to 
go on supporting their private methods (?)

> * Lots of churn relative to STABLE, which will make backporting changes
>   somewhat more difficult, particularly if they have any build
>   implications.  There would be a lot of changes to the naming of include
>   files, which would touch basically every file.

We will see in practice.  We do not change that often things related to 
the building system.  If backporting changes really appears to be 
difficult, even for bug-fix patches only, then we could consider 
releasing INN 2.6.0 just after a final 2.5.4 release for the 2.5 branch.

> * I would propose leaving the files imported from rra-c-util verbatim, but
>   the coding style is slightly different than INN's.  (For INN, I used a
>   hybrid of my style and INN's native style, particularly around block
>   comments, and my own is somewhat different.)  This means that some files
>   in INN (although ones segregated in their own directories for the most
>   part) would have a slightly different style.

Not really a problem, I believe.  There are already lots of INN's 
"native" styles :-)

Julien ÉLIE

« – Hou hou !
   – Ouille, ouille !
   – Ouf !
   – Où ouf ? » (Astérix)

More information about the inn-workers mailing list