Solaris & automake problem identified and workarounds

Hi.

Looking further into the Solaris build problem..

I still do not quote understand the automake Make files... there is two
rules:

A explicit rule:

ufs/store_dir_ufs.o: ufs/store_dir_ufs.c
        source='ufs/store_dir_ufs.c' object='ufs/store_dir_ufs.o'
libtool=no \
        depfile='$(DEPDIR)/ufs/store_dir_ufs.Po'
tmpdepfile='$(DEPDIR)/ufs/store_dir_ufs.TPo' \
        $(CCDEPMODE) $(depcomp) \
        $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS)
$(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o u
fs/store_dir_ufs.o `test -f ufs/store_dir_ufs.c || echo
'$(srcdir)/'`ufs/store_dir_ufs.c

And a implicit rule:

.c.o:
        source='$<' object='$@' libtool=no \
        depfile='$(DEPDIR)/$*.Po' tmpdepfile='$(DEPDIR)/$*.TPo' \
        $(CCDEPMODE) $(depcomp) \
        $(COMPILE) -c -o $@ `test -f $< || echo '$(srcdir)/'`$<

First question: Why both these rules?

The failing compile line reads:

source='ufs/store_dir_ufs.c' object='ufs/store_dir_ufs.o' libtool=no \
depfile='.deps/ufs/store_dir_ufs.Po'
tmpdepfile='.deps/ufs/store_dir_ufs.TPo' \
depmode=gcc /bin/sh ../../../../commit/cfgaux/depcomp \
gcc -DHAVE_CONFIG_H -I. -I../../../../commit/src/fs -I../../include -I.
-I../../include -I../../../../commit/include
-I../../../../commit/src/ -g -Wall -c -o ufs/store_dir_ufs.o `test
-f ../../../../commit/src/fs/ufs/store_dir_ufs.c || echo
'../../../../commit/src/fs/'`ufs/store_dir_ufs.c
gcc: ufs/store_dir_ufs.c: No such file or directory

Experimenting with the makefile shows that the Sun make program is
perhaps a bit too smart for it's own good. It is the explicit rule which
screws up, looking like the make program substitutes the path in the
test command. If the explicit rules are removed then things builds like
expected.

Reading the Sun make man page reveals:

     If a target or a dependency file is found using VPATH, then
     any occurrences of the word that is the same as the target
     name in the subsequent rules will be replaced with the
     actual name of the target derived from VPATH.

Which seems like a somewhat sound thing to do, except that it apparently
partly fails to do the substitution when the path is next to other
characters such as quotes...

So to fix the problem, one can either rewrite the explicit rules using
quotes around the path, or remove them entirely and always use the
implicit rule with $<.

ufs/store_dir_ufs.o: ufs/store_dir_ufs.c
        source='ufs/store_dir_ufs.c' object='ufs/store_dir_ufs.o'
libtool=no \
        depfile='$(DEPDIR)/ufs/store_dir_ufs.Po'
tmpdepfile='$(DEPDIR)/ufs/store_dir_ufs.TPo' \
        $(CCDEPMODE) $(depcomp) \
        $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS)
$(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o u
fs/store_dir_ufs.o `test -f 'ufs/store_dir_ufs.c' || echo
'$(srcdir)/'`'ufs/store_dir_ufs.c'

Actually, to me it seems automake tries too hard to deal with odd VPATH
implementations. automake is confused by Suns make who is confused by
automake. Two things trying to be smart about a backward solution
colliding in the middle...

Now, after reading the automake generated make files I am not all too
happy about how automake deals with VPATH. It both tries to use it, and
makes rules which is completely ignorant to VPATH and instead implements
it's own method, leaving me with the personal view that it is more
automake to blaim than Sun make for this problem. But we have to live
with it I guess.

I would be very happy if automake could be told to ignore broken VPATH
makes, and instead assume $< always works. A make having a working
implementation of $< has been a requirement in Squid for a quite a
while.

Regards
Henrik
Received on Mon Oct 15 2001 - 06:07:18 MDT