[Top][All Lists]
[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