Dependencies, libstorage, and libinnhist

[Jeffrey M. Vinocur]

On Sun, 8 Sep 2002, Russ Allbery wrote:

> Recursive make is evil.
> 
> I'd really like to require a compiler that supports -c with -o so that we
> can easily build without recursing.  Are we about at the point where we
> can do that?  gcc supports that, of course, as does Forte as near as I can
> tell, but I've seen some bug reports about that assumption within the past
> four years or so, so I know some vendor compilers still don't.
> 
> If we could assume -c with -o so that we can tell the compiler to place
> the object file in the right place, I'd start looking at rewriting the
> build machinery so that make never had to recurse at all, at least in the
> library directories.

I finally got a chance to pursue this a bit.  I definitely don't know how 
widespread the necessary compiler support is.  On a whim, I queried one of 
the gcc folks who also didn't know, but had an interesting suggestion.

Apparently there is AC_PROG_CC_C_O in autoconf, which would allow us to 
detect the desired functionality and switch use the following in 
Makefile.global.in:

INPUT_AND_OUTPUT = @INPUT_AND_OUTPUT@

.c.o:
        $(CC) $(CFLAGS) $(INPUT_AND_OUTPUT)

where depending on what autoconf finds, $INPUT_AND_OUTPUT is set to 
"-c -o $@ $<" normally and "-c $<; mv $(@F) $@".  (Sadly the test only 
does a #define and not a substitution, so we'd have to replace 
@INPUT_AND_OUTPUT@ ourselves, but whatever.)


There's a big caveat, though.  This only works if no two .o files have the 
same basename.  I figure we can rename the things in tests/ with no 
hassle, but we have a few other collisions anyway:

current/inn > find . -name '*.c' | grep -v tests \
            | xargs -n1 basename \
            | sort | uniq -c | sort -n \
            | grep ' [^1]     '
      2 article.c
      2 buffer.c
      2 expire.c
      2 misc.c
      2 python.c
      2 version.c
      3 perl.c


I don't know if this is worth pursuing.

-- 
Jeffrey M. Vinocur
jeff at litech.org