On Fri, Jan 31, 2020 at 3:24 AM Hans-Bernhard Bröker <[email protected]> wrote: > > 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 >
Thanks for tracking this down. Do you know why the file moved? Is there any way of generating the file in the srcdir? > 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. I put all the code for XS modules in the same Makefile.am because it isn't easy to get right. > 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. Interesting.
