bug-automake
[Top][All Lists]
Advanced

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

bug#10852: VPATH builds cannot recover from missing parser header


From: Stefano Lattarini
Subject: bug#10852: VPATH builds cannot recover from missing parser header
Date: Mon, 20 Feb 2012 14:58:13 +0100

Hi Akim.

On 02/20/2012 02:24 PM, Akim Demaille wrote:
> I am having problems in Bison (current master) to recover
> from a lost parse-gram.h, generated from parse-gram.y
> with regular Automake (1.11.3) handling:
> 
>> AM_YFLAGS = -d -v --warnings=all,error --report=all
>>
>> src_bison_SOURCES =                             \
>>   ...
>>   src/output.h                                  \
>>   src/parse-gram.y                              \
>>   src/print-xml.c                               \
>>   ...
> 
> 
> Makefile.in:
> 
>> src/parse-gram.h: src/parse-gram.c
>>      @if test ! -f $@; then rm -f src/parse-gram.c; else :; fi
>>      @if test ! -f $@; then $(MAKE) $(AM_MAKEFLAGS) src/parse-gram.c; else 
>> :; fi
> 
> The problem is that src/parse-gram.c is in $(srcdir), so
> its occurrences in the commands should be prefixed by
> $(srcdir)/.  Actually, I don't understand why we don't
> simply use $< (lemme guess: it's not portable for non
> generic recipes,
>
Exactly; see the first node here:

  http://www.gnu.org/software/autoconf/manual/html_node/Portable-Make.html

> ISTR some horrors in this area that my brains decided to quickly forget :).
>
;-)

> Also, why two "if"?
>
For the sake of "make -n": at least GNU make and Solaris make execute
recipes containing the $(MAKE) string even when they are running in dry
mode; so if we didn't break the recipe above in two invocations, the
file 'src/parse-gram.c' would be removed even upon "make -n".  Not nice.

> In case some concurrent execution of Make would already have
> provided $@ in the meanwhile?
>
Nope; see above.

> The following patch extends a test which is aimed at checking
> this, but does it in a non-vpath build :)
>
But the test is wrong, because it checks that the Yacc-generated .h and .c
files are placed in the $srcdir, while we expect them to be placed in the
$builddir.  Do the tests added by your patch work for you?  They don't work
for me (as I would have expected BTW).

> I have a question though.  I don't understand how come
> Make realizes it must provide $@ in srcdir too.
> 
> The Makefile.in features:
> 
>> .y.c:
>>      $(AM_V_YACC)$(am__skipyacc) $(SHELL) $(YLWRAP) $< y.tab.c $@ y.tab.h 
>> $*.h y.output $*.output -- $(YACCCOMPILE)
> 
> and at runtime I have:
> 
>> /bin/sh ../../build-aux/ylwrap ../../src/parse-gram.y y.tab.c 
>> ../../src/parse-gram.c y.tab.h ../../src/parse-gram.h y.output 
>> ../../src/parse-gram.output -- ./tests/bison -y -d -v --warnings=all,error 
>> --report=all 
>> updating ../../src/parse-gram.h
>> ../../src/parse-gram.output is unchanged
> 
> which is what is expected, but I don't understand why
> it works: that $< is prefixed with $(srcdir), this I
> understand, but why does it appear on address@hidden
>
Unless I'm somehow sorely mistaken, that is not automake's doing; it's the
make implementation that does such a rewrite.  Which is highly unexpected
BTW.  Which make implementation are you using?

> I have to specify $(srcdir)/ by hand on similar patterns,
> why does it work here?
>
No idea.

Regards,
  Stefano





reply via email to

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