At 2025-12-08T11:47:37+0100, Bruno Haible wrote: > G. Branden Robinson wrote: > > > So, how does your Makefile rule for src/preproc/pic/pic.cpp look > > > like? > > > > I don't have one. I'm relying on Automake. > > > > Here's what it puts in groff's build/Makefile. > > > > .ypp.cpp: > > $(AM_V_YACC)$(am__skipyacc) $(SHELL) $(YLWRAP) $< y.tab.c $@ y.tab.h > > `echo $@ | $(am__yacc_c2h)` y.output $*.output -- $(YACCCOMPILE) > > The Automake generated .y.c rule is known to be broken in multiple > ways:
:( > When executed in a VPATH build, > - The .c file gets generated in the build directory. But since it > requires special tools to rebuild it, we need to distribute it in > the tarballs, and by the GNU Coding Standards > <https://www.gnu.org/prep/standards/html_node/Makefile-Basics.html> > the file should be generated in the source directory. Yup. And we do this,[1] but I just made a change to "pic/main.cpp"[2] and that make Make think (I assume correctly) that pic.cpp needed to be remade. However, perhaps I was led astray by my recent experience with Savannah #67754 (referenced in the initial message of this thread), and something different is going wrong. This has me scratching my head then, as the source directory obviously exists, so it sounds like Automake's .ypp.cpp rule is trying to create the .cpp file in the wrong directory? My kludgy patch to "ylwrap" seems to verify that hypothesis. I wonder what puts it in the correct place for "make dist", then. > - The #line directives in the .c file refer to a nonexistent file > once it has been moved from the build directory to the source > directory. This leads to error if 'lcov' is used later. Hrm. :-/ Attacking the groff codebase with "gcov" was on my wishlist for the next calendar year. > You may want to report it as an Automake bug. (Many packages don't use > ylwrap any more; they invoke 'bison' directly. GNU groff is one of the > few packages that does not make use of GNU Bison features.) We're consciously trying to maintain compatibility with byacc as well.[3][4] It sounds like the bug may already have been reported: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=7884 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39666 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=33668 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54390 The last two sound exactly like my problem, and the second yours about the '#line' directive. Since the youngest of those bugs is almost 4 years old,[5] I suppose I'm going to have to work around this issue, and advise our Git repository users how to do the same (since any time any committer changes a prerequisite of pic.cpp, this beast will rear its head again). While normally I build in a separate tree (really just a subdirectory named "build" in my Git checkout), I'll try doing an in-tree build once after dirtying "pic.cpp"'s prerequistes, and see if that restores the checkout to a copasetic state for further out-of-tree builds. If that works, I'll advise our more engaged users of this procedure in our "HACKING" file. Regards, Branden [1] https://fossies.org/linux/misc/groff-1.23.0.tar.gz/ [2] https://cgit.git.savannah.gnu.org/cgit/groff.git/commit/?id=ff65f930ead64f98bb86b7c5ea232f0d162300a1 [3] https://cgit.git.savannah.gnu.org/cgit/groff.git/tree/NEWS?h=1.23.0#n588 [4] https://cgit.git.savannah.gnu.org/cgit/groff.git/tree/INSTALL.REPO?h=1.23.0#n32 [5] If I'm understanding Mike Frysinger's response to submitter Sam James correctly, the Automake developers regard this as a "wontfix" issue because the POSIX specification for yacc doesn't support out-of-tree compilation and so when you run "bison -y", you get what you ask for, and Automake ain't gonna budge--it expects you to use Bison, and only in non-POSIX mode. I could be wrong, though.
signature.asc
Description: PGP signature
