Re: can't compile Parsetexi.xs

[Hans-Bernhard Bröker]

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
> >      .../texinfo/tp/Texinfo/XS/parsetexi/Parsetexi.xs:13:0:
> >    /usr/lib/perl5/5.26.1/x86_64-linux-thread-multi/CORE/parser.h:22:3:
> >      error: conflicting types for ‘yy_stack_frame’
> >     } yy_stack_frame;
> >       ^~~~~~~~~~~~~~
> >    In file included from
> >      /usr/lib/perl5/5.26.1/x86_64-linux-thread-multi/CORE/perl.h:3939:0,
> >        from .../texinfo/tp/Texinfo/XS/parsetexi/Parsetexi.xs:6:
> >    /usr/lib/perl5/5.26.1/x86_64-linux-thread-multi/CORE/parser.h:22:3:
> >      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

        $(srcdir)/parsetexi/Parsetexi.c

whereas the fresh one built it in

        $(builddir)/parsetexi/Parsetexi.c

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_LDFLAGS = $(AM_LDFLAGS) $(LTLIBINTL) $(LTLIBICONV)
+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.