[Top][All Lists]

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

Re: can't compile Parsetexi.xs

From: Hans-Bernhard Bröker
Subject: Re: can't compile Parsetexi.xs
Date: Fri, 31 Jan 2020 04:24:11 +0100
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.4.2

Am 30.01.2020 um 20:50 schrieb Gavin Smith:
On Thu, Jan 30, 2020 at 01:18:09PM +0100, Werner LEMBERG wrote:
   In file included from
     error: conflicting types for ‘yy_stack_frame’
    } yy_stack_frame;
   In file included from
       from .../texinfo/tp/Texinfo/XS/parsetexi/Parsetexi.xs:6:
     note: previous declaration of ‘yy_stack_frame’ was here
    } yy_stack_frame;

Oh, so I wasn't hallucinating when it started doing that on my newly set up machine (Cygwin on Windows10). I didn't get around to investigate that yet, so it's a bit of a relief to hear that this happens to other people, too ;-)

What is odd is that that "parser.h" file is not the one that should have
been included.  It was the file inside the parsetexi directory that
should have been included.  I wonder if there needs to be an -I flag
added to make sure that that directory is searched.  It was relying on
finding the include file in the same directory as the source file
(parsetexi/Parsetexi.c and parsetexi/parser.h).  It is odd that the
parser.h in Perl's directories is used instead.

It took some digging, but I believe I've found the trigger for this breakage. It depends on where Parsetexi.c is generated in VPATH builds.

Older builds had it in


whereas the fresh one built it in


The way this allowed the build to work at all is through the C preprocessor's rule that includes will be looked for initially in the same folder the including source is in. As long as Parsetexi.c was in the same folder as parser.h, it picked up that one. Now it doesn't, and since there's no -I$(srcdir)/parsetexi anywhere in Makefile.am, it has no chance to find it there. This informs my proposed fix:

diff --git a/tp/Texinfo/XS/Makefile.am b/tp/Texinfo/XS/Makefile.am
index ea08389d4..587d15666 100644
--- a/tp/Texinfo/XS/Makefile.am
+++ b/tp/Texinfo/XS/Makefile.am
@@ -153,6 +153,7 @@ EXTRA_DIST += $p/Parsetexi.xs

 Parsetexi_la_LIBADD = $(top_builddir)/gnulib/lib/libgnu.la
+Parsetexi_la_CPPFLAGS = -I$(srcdir)/parsetexi $(AM_CPPFLAGS)

 BUILT_SOURCES=parsetexi/element_types.c \
               parsetexi/element_types.h \

A more elegant solution might require giving XS/parsetexi its own Makefile.am. Then the automatically added -I$(srcdir) would take care of this en-passant.

Note that this was quite tricky to isolate because as long as there is either a generated $(srcdir)/parsetexi/Parsetexi.c, or a $(builddir)/parsetexi/.deps/Parsetexi.Plo dependency file mentioning it, make will re-create the file in that location. This establishes a self-stabilizing situation different from normal behaviour.

Only in a completely fresh check-out (-->no Parsetexi.c) with a completely fresh build dir (-->no Parsetexi.Plo) does the bug become noticeable, because then the actual Makefile's VPATH rules kick in and generate this file in $(builddir)/parsetexi.

reply via email to

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