Re: SUN make and gcc 3.0: committed changes to branch

[Hans-Peter Nilsson <hans-peter dot nilsson at axis dot com>]

> Date: Wed, 30 May 2001 17:05:59 -0400
> From: Phil Edwards <pedwards@disaster.jaj.com>

> On Wed, May 30, 2001 at 03:11:58PM -0700, Benjamin Kosnik wrote:
> > >    -rw-r--r--   1 pedwards sysadmin   18939 May 30 16:47 cxxabi.h
> > >    -rw-r--r--   1 pedwards sysadmin    2514 May 30 16:47 new
> > >    -rw-r--r--   1 pedwards sysadmin    4400 May 30 16:47 typeinfo
> > 
> > likely these are from the libsupc++ header install. It's done a bit 
> > differently than the rest, and uses native automake rules. 
> > 
> > if you look in libsupc++/Makefile, say looking for "install," you should 
> > see the root cause of this.
> 
> Yep, I saw that.  What I can't figure out (and didn't take much time
> examining) is why the other two libsupc++ headers aren't here also.
> There's a single variable listing all five of them, and it's that variable
> which the Makefile.in is looping over.  But only these three are here.

This passage of the SUN make manpages might shed some light:

       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

They really mean "any occurrence".  It goes on with an example
using *bare words*, i.e. not just through variables such as
"$<". In the example VPATH=./subdir; a verbatim "file.c" in the
rule gets replaced with "./subdir/file.c".

But that does not explain why exception and exception_defines.h
don't get the same treatment.  There's one detail: those are the
*first* and *last* names in that list.  In the rule, we have
"list='$(glibcppinstall_HEADERS)'".  That in turn suggests an
explanation for the rest: the single-quote mark makes them seen
as "'exception" and "exception_defines.h'" in the rule, when
expanding $(glibcppinstall_HEADERS), so they don't match the
exact VPATH contents.  A low-level solution is to filter "p"
through basename.

The question is what to actually do.  Do we just punt and say
"use GNU make", or do we fix this?  I think automake should
cater to this misfeature in the automatic rule generation, but
it seems there's no newer version with this fixed, and a new
version might have too great impact this late.  Can I suggest
not using the automake rule, but use the actual expansion, fixed
by using basename?  I'll come up with a patch anyway.

brgds, H-P