bug-automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Yet another bug in Lex/Yacc support (maintainer-mode).


From: Ralf Wildenhues
Subject: Re: Yet another bug in Lex/Yacc support (maintainer-mode).
Date: Sat, 18 Sep 2010 07:37:44 +0200
User-agent: Mutt/1.5.20 (2010-08-04)

Hi Stefano,

* Stefano Lattarini wrote on Thu, Sep 16, 2010 at 06:34:06PM CEST:
> While trying to improve and extend test `mmodely.test', I stumbled
> upon the bug exposed by the attached test script (weird bug, BTW:
> it's triggered with GNU make and FreeBSD make, but not with Solaris
> make; role reversal for once ;-).

VPATH handling is an ugly subject.  autoconf.texi has a longish story
about it, and the full details of GNU make semantics are in its manual,
info make 'Search Algorithm'.

> I suspect the bug is due to some incomplete VPATH rewrite somewhere
> in automake; I tried this simplicistic patch:

>  --- a/lib/am/lex.am
>  +++ b/lib/am/lex.am
>  @@ -18,7 +18,7 @@
>   ## See the comment about am__skipyacc in yacc.am.
>   if %?MAINTAINER-MODE%
>   if %?FIRST%
>  address@hidden@am__skiplex = test -f $@ ||
>  address@hidden@am__skiplex = test -f '$@' || test -f '$(srcdir)/$@' ||
>   endif %?FIRST%
>   endif %?MAINTAINER-MODE%
[...]
> but it did no good (failure still there, although due to a different
> reason apparently).

No, the patch is not right because GNU make will, once it has determined
the target is out of date, it will throw away the vpath prefix for it,
and rebuilds the file locally.  Our rule doesn't do that, and that
confuses GNU make in the following.

I'm wondering whether this is a case of "don't do it when it hurts".
I mean, if you don't want lex to run, all you need to take care of is
not creating a new lex file in the build tree.  Or is that something
that happens as a by-product of something else automake does?

Fixing this properly would probably require automake to special-case
rules for compiling output files from lex/yacc (i.e., lex.c -> lex.o)
so the standard inference rule is not used, but we implement vpath
search manually.  Alternatively, even more uglily, copy the wrong .c
file to the build tree to serve as fake.  Neither seems appealing.

Cheers, and thanks for the bug report!
Ralf



reply via email to

[Prev in Thread] Current Thread [Next in Thread]