[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 15:21:25 +0100
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.4.2

Am 31.01.2020 um 13:38 schrieb Gavin Smith:
On Fri, Jan 31, 2020 at 3:24 AM Hans-Bernhard Bröker
<address@hidden> wrote:

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


Thanks for tracking this down. Do you know why the file moved?

I'm not entirely sure, but it could be the automake version. It might even be that this source tree just happened to have the file in $(srcdir) from an in-tree build made in this sandbox in the past, and this perpetuated itself ever since.
Is there any way of generating the file in the srcdir?

I don't think so, and frankly, I think it would be the wrong thing to do. Parsetexi.c is a built file, so it really should be in $(builddir). That's how it's supposed to be for all files built by configure and make. Only the autotools themselves (autoconf/automake/aclocal) place their output into the srcdir.

Note that MiscX.c, TestXS.c and XSParagraph.c are also in $(srcdir) now.

That means that in a current, clean VPATH build, the only generated .c files in $(srcdir) are command_data.c and element_types.c, and that's because their generator rule is manually invoked that way.

There's also a bit of a lack of consistency there: command_ids.h is in git, but command_data.c is not, although they're both generated in the same step. IMHO, none of these generated files should be in git. It's enough if they're in the tarball, for users who may not want to generate them.

reply via email to

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