Dependencies, libstorage, and libinnhist

[Russ Allbery]

Jeffrey M Vinocur <jeff at litech.org> writes:

> I finally got a chance to pursue this a bit.  I definitely don't know
> how widespread the necessary compiler support is.

It's required by POSIX, I believe (I'll check when I get to work), so it
should be getting more widespread.

> 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.)

My first reaction on this was that it sounded really promising, but that
it was likely to pose problems for libtool where it isn't this simple.
Then I checked, and libtool already knows how to deal with this itself, so
if we're building with libtool, libtool handles converting -c -o to the
right thing.  Cool.  So if we want to require libtool for building, we
don't have to do any work at all.

If we don't want to require libtool (and I lean in that direction), we can
rip off the test from libtool and use it ourselves for the non-libtool
case and do something like the above when we're not using libtool.

> 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,

No need; that's exactly why all the source files in tests/ end in -t.  :)

> 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.

The low-hanging fruit is the storage and history APIs, where we've already
had a ton of dependency handling problems because of recursive make, and
where there's nothing really gained from being able to build the
individual subdirectories of storage/ or history/ by themselves.  There
aren't any collisions under storage/ or under history/, so we don't have
to worry about that issue there.  I think it's definitely worth it for
those.

I don't think converting the whole tree is probably worth it right now;
the other dependency problems are occasionally mildly annoying, but aren't
that severe, and we lose more by converting the entire tree since it often
*is* very convenient to be working on something in the nnrpd/ directory of
an otherwise built tree and just do make warnings in that subdirectory to
recompile the stuff one is working on (for example).

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

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