GNU bug report logs - #39666
distcheck for VPATH build: #line directives of generated YACC and LEX c-files in tarballs

Previous Next

To reply to this bug, email your comments to 39666 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Jannick" <thirdedition <at> gmx.net>
To: <bug-automake <at> gnu.org>
Subject: distcheck for VPATH build: #line directives of generated YACC and LEX
 c-files in tarballs 
Date: Tue, 18 Feb 2020 10:59:43 +0100

[Message part 1 (text/plain, inline)]

$ automake --version
automake (GNU automake) 1.16.1

For c-files generated by LEX and YACC in the build process the script ylwrap
takes care, among other things, that the relative file paths in #line
directives are correct.  The generated files are part of distribution
tarballs, where they sit next to their corresponding source YACC or LEX
file; it appears that their #line directives are the same as in the build
process.  This causes an issue when 'make distcheck' is run in a (strict)
VPATH build: In the distribution tarball the relative #line directives
pointing to the source YACC or LEX file are incorrect.

So my question is under the premise of a VPATH build:  Is there a remedy for
the incorrect paths in these #line directives (OTHER THAN running configure
and make in the top src dir)?  Or this is rather a bug in automake to be
fixed?  The documentation appears to be silent about that (or am I missing
something here?)

The attached minimal sample package demonstrates the issue.  Sources sit in
the src subdir. The package was created by 'make distcheck' for a VPATH
build, i.e.:  mkdir bld && cd bld && ../configure  && make && make distcheck
Please check the #line directives in parse.c and scan.c. (I did not have
automake generate corresponding header files.)


Separately, when distcleancheck fails for an elaborate package I find the
part of the error message a bit misleading (sample below).  It could be
interpreted in the way that './share/info/dir' should be uninstalled, too,
which supposedly it should NOT be, since the check passes regardless of the
dir file.  So, it would be great if the dir file could be dropped in the
currently prompted error message. (Of course, it is technically correct to
say that the dir file is left after uninstall.)

ERROR: files left after uninstall:
./path/to/file/forgotten/to/uninstall
./share/info/dir


Many thanks for your insights,
J.

PS: Please cc me in replies. Thanks!

[prog-0.0.1.tar.gz (application/x-gzip, attachment)]

Message #8 received at 39666 <at> debbugs.gnu.org (full text, mbox):

From: Karl Berry <karl <at> freefriends.org>
To: thirdedition <at> gmx.net
Cc: 39666 <at> debbugs.gnu.org
Subject: Re: bug#39666: distcheck for VPATH build: #line directives of
 generated YACC and LEX c-files in tarballs 
Date: Fri, 20 Nov 2020 19:20:03 -0700

Hi Jannick - (sorry for the delayed reply)

    So my question is under the premise of a VPATH build: Is there a
    remedy for the incorrect paths in these #line directives (OTHER THAN
    running configure and make in the top src dir)?

My gut reaction is that make distcheck is not intended to be run under
VPATH and thus the incorrect #line's are not exactly a bug. Although I
would have nothing against fixing ylwrap to handle that situation, I'm
not going to have the energy to tackle it. Sorry. Maybe someone else
here (or you?) would be interested?

I could update the documentation as a "known deficiency", at least, I
guess. I'll mark this bug confirmed until I get around to that, assuming
there's no real fix in the meantime.

As for your other report:

    ... it would be great if the dir file could be dropped in the
    currently prompted error message. [...]

    ERROR: files left after uninstall:
    ./path/to/file/forgotten/to/uninstall
    ./share/info/dir

There is code now that tries to remove the dir file from that list.
From lib/am/distdir.am:

  am__distuninstallcheck_listfiles = $(distuninstallcheck_listfiles) \
    | sed 's|^\./|$(prefix)/|' | grep -v '$(infodir)/dir$$'

I am not sure when it was added (I can't find it in the ChangeLog),
which makes me think it is not doing its job (maybe $(infodir) has some
other value?). If you can make a little tarball that reproduces the
problem with the current automake and submit it as a separate bug, that
at least should not be difficult to fix.

Thanks for the reports,
Karl

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.