emacs-bug-tracker
[Top][All Lists]
Advanced

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

bug#10852: closed (VPATH builds cannot recover from missing parser heade


From: GNU bug Tracking System
Subject: bug#10852: closed (VPATH builds cannot recover from missing parser header)
Date: Fri, 29 May 2020 00:53:01 +0000

Your message dated Thu, 28 May 2020 18:51:55 -0600
with message-id <202005290051.04T0ptSH013585@freefriends.org>
and subject line Re: bug#10852: VPATH builds cannot recover from missing parser 
header
has caused the debbugs.gnu.org bug report #10852,
regarding VPATH builds cannot recover from missing parser header
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
10852: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10852
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
--- Begin Message --- Subject: VPATH builds cannot recover from missing parser header Date: Mon, 20 Feb 2012 14:24:15 +0100
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, ISTR some horrors in this area that my
brains decided to quickly forget :).  Also, why two "if"?
In case some concurrent execution of Make would already have
provided $@ in the meanwhile?

The following patch extends a test which is aimed at checking
this, but does it in a non-vpath build :)

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 $@?  I
have to specify $(srcdir)/ by hand on similar patterns,
why does it work here?

Thanks!

Attachment: 0001-tests-check-yacc-parser-header-recovery-in-vpath-bui.patch
Description: Binary data


--- End Message ---
--- Begin Message --- Subject: Re: bug#10852: VPATH builds cannot recover from missing parser header Date: Thu, 28 May 2020 18:51:55 -0600
Back on this bug from 2012,
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=10852

    ak> Also, why two "if"?
    sl> For the sake of "make -n": 

    * doc/automake.texi (Multiple Outputs): Split commands than
    reinvoke $(MAKE) to avoid file removals during dry runs.

I pushed Akim's patch.

Regarding the bigger issue mentioned in the middle:

> It basically boils down to whether the maintainer-src-tree should
> look like a fresh check-out, or a fresh tarball.  I think it should
> look like a tarball.

Personally I agree, but unless I'm misunderstanding, GNU packages have
moved quite in the other direction, aggressively minimizing the source
tree to be as much like a checkout as possible. E.g., there is no
ChangeLog file in Automake or most other git-based GNU packages.

I certainly have no appetite for attempting to change this, and it would
fly in the face of the established "git practice" of the last N years,
so I doubt such a policy would be warmly welcomed. So I'm closing this
bug. If I'm missing the point, can discuss further, of course. --best, karl.


--- End Message ---

reply via email to

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