This is the mail archive of the
mailing list for the GCC project.
Re: SUN make and gcc 3.0: committed changes to branch
- To: pedwards at disaster dot jaj dot com
- Subject: Re: SUN make and gcc 3.0: committed changes to branch
- From: Hans-Peter Nilsson <hans-peter dot nilsson at axis dot com>
- Date: Thu, 31 May 2001 07:18:10 +0200
- CC: bkoz at redhat dot com, hans-peter dot nilsson at axis dot com, gcc-patches at gcc dot gnu dot org, libstdc++ at gcc dot gnu dot org
> Date: Wed, 30 May 2001 17:05:59 -0400
> From: Phil Edwards <firstname.lastname@example.org>
> 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"
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.