BUG: Solaris make & automake, VPATH, subdir sources and SUBDIR_OBJECTS

Sumamry for automake:

automake 1.5 with VPATH builds using the Sun make environment and
subdirectory sources and SUBDIR_OBJECTS is failing due to partial
pattern replacement by the Sun make on the explicit .c.o rule. The
implicit rule works fine.

I'm happy to prep a patch for this, but which of the two solutions
Henrik has isolated is preferrable?

1) Quote the paths used in the explicit rule - probably the easiest
alteration.
2) Only emit explicit rules when the sources ARE in the same relative
dir in the source tree. (Note: I haven't confirmed with Henrik that the
source is built in the right location doing this... so from my point of
view this is not preferred).

----- Original Message -----
From: "Henrik Nordstrom" <hno@marasystems.com>
To: "Squid Developers Mailinglist" <squid-dev@squid-cache.org>
Sent: Monday, October 15, 2001 10:08 PM
Subject: 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?

Probably an automake oversight. Automake has the capability to do two
things with directories, sources and objects that are somewhat
orthogonal to each other:
1) compile source from another dir to an object file.
2) specify that built objects are placed in the same relative path as
the source file.

We use 2) which is a recent feature, without it the rule would be

store_dir_ufs.o: ufs/store_dir_ufs.c
....

which quite obviously _needs_ the specific rule, as the implicit has no
ability to find source not in the current dir or the VPATH dir. Also the
placement of the object file needs to be specified.

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

I suspected something like this earlier , but couldn't quite believe it
:}.

>
> 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 whats happening is that the test -f which is meant to replace VPATH
capability (because the source is in a subdir) is passing because of the
substition, but the substition being partial means that the emitted path
is wrong.

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

Using the $< is fine IFF the relative path is consistent and we are
happy with potentially random object file location... can you confirm
that using $< puts the object files in the same relative path as the
source files? (ie not the current directory).

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

This looks good to me.

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

It's not VPATH it's dealing with here, it's source not in the current
dir or the VPATH dir with optional explicit placement of the object
file.

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

As above, this isn't a VPATH issue, it's for arbitrary source location
and object file location.

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

Rob
Received on Mon Oct 15 2001 - 06:57:15 MDT