[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: can't compile Parsetexi.xs
From: |
Gavin Smith |
Subject: |
Re: can't compile Parsetexi.xs |
Date: |
Fri, 31 Jan 2020 12:38:48 +0000 |
On Fri, Jan 31, 2020 at 3:24 AM Hans-Bernhard Bröker
<address@hidden> 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.