From: simon.marchi@polymtl.ca
To: gdb-patches@sourceware.org
Cc: Simon Marchi <simon.marchi@efficios.com>
Subject: [PATCH v2 09/19] gdb: add check for stale build generated files
Date: Sat, 5 Sep 2026 00:23:12 -0400 [thread overview]
Message-ID: <20260905042353.1702204-10-simon.marchi@polymtl.ca> (raw)
In-Reply-To: <20260905042353.1702204-1-simon.marchi@polymtl.ca>
From: Simon Marchi <simon.marchi@efficios.com>
Before this series, building gdb generates a file called cp-name-parser.c,
from cp-name-parser.y. After this series, cp-name-parser.c is a source
file written by hand checked in git. When doing out of tree builds, a
leftover generated cp-name-parser.c in the build directory would interfere
with the build. To make "cp-name-parser.o", it will prefer the stale
cp-name-parser.c from the build directory rather than the good
cp-name-parser.c from the source directory. Debugging the build failure
that arises from this can be difficult and time consuming, especially if
you have never hit the problem before.
I propose to add a check in the Makefile to point out if there exists a
file in the build directory that is known to be stale and that could
interfere with the build.
The alternative is obviously to avoid naming the new file
"cp-name-parser.c", but I don't want to avoid using a good and logical
file name just because of that.
The check looks like this when it catches something:
Error: stale generated files found in the build directory:
cp-name-parser.c
They are left over from an older build of GDB and shadow the
source files with the same name. Run "make clean" (or delete
them manually) then build again.
I made "make clean" remove those files, because why not, it seems
convenient.
The check and removal in "make clean" only happen when the source directory
is different from the build directory. For in-tree builds, a stale
generated cp-name-parser.c file would presumably prevent checking out a git
commit that has a tracked cp-name-parser.c file.
This patch only adds the machinery, the following patch adds
cp-name-parser.c to the STALE_GENERATED_FILES list. I have done it in this
order to avoid having some commits that could present the conflict but
don't have the check.
Change-Id: I109ba215b3e30debe82b711efb8826668fea0969
---
gdb/Makefile.in | 37 ++++++++++++++++++++++++++++++++++++-
1 file changed, 36 insertions(+), 1 deletion(-)
diff --git a/gdb/Makefile.in b/gdb/Makefile.in
index e6c1587f4767..6cb5482bbc66 100644
--- a/gdb/Makefile.in
+++ b/gdb/Makefile.in
@@ -2074,6 +2074,15 @@ YYOBJ = $(filter-out ada-lex-gen.o,$(patsubst %.c,%.o,$(YYFILES)))
# The headers bison/byacc and flex generate alongside the files above.
YYHFILES = $(patsubst %-gen.c,%-gen.h,$(YYFILES))
+# Files that used to be generated in the build directory (for builds from git
+# at least), but are now committed source files. A leftover copy in an
+# existing build directory would shadow the real source file with the same name
+# and cause a hard to debug build failure.
+#
+# Files in there can be removed after a while, once build directories with them
+# are unlikely to be around.
+STALE_GENERATED_FILES =
+
# Things which need to be built when making a distribution.
DISTSTUFF = $(YYFILES) $(YYHFILES)
@@ -2091,9 +2100,32 @@ generated_files = \
# Flags needed to compile Python code
PYTHON_CFLAGS = @PYTHON_CFLAGS@
-all: gdb$(EXEEXT) $(CONFIG_ALL) gcore gstack gdb-add-index
+all: check-stale-generated-files gdb$(EXEEXT) $(CONFIG_ALL) gcore \
+ gstack gdb-add-index
@$(MAKE) $(FLAGS_TO_PASS) DO=all "DODIRS=$(SUBDIRS)" subdir_do
+# Error out if the build directory contains known stale generated files, which
+# would shadow the source files with the same name and cause a hard to debug
+# build failure. See STALE_GENERATED_FILES above.
+.PHONY: check-stale-generated-files
+check-stale-generated-files:
+ @if test "$(srcdir)" != "."; then \
+ stale=""; \
+ for f in $(STALE_GENERATED_FILES); do \
+ if test -f "$$f"; then \
+ stale="$$stale $$f"; \
+ fi; \
+ done; \
+ if test -n "$$stale"; then \
+ echo "Error: stale generated files found in the build directory:" >&2; \
+ echo " $$stale" >&2; \
+ echo "They are left over from an older build of GDB and shadow the" >&2; \
+ echo "source files with the same name. Run \"make clean\" (or delete" >&2; \
+ echo "them manually) then build again." >&2; \
+ exit 1; \
+ fi; \
+ fi
+
# Rule for compiling .c files.
%.o: %.c
$(COMPILE) $<
@@ -2417,6 +2449,9 @@ clean mostlyclean: $(CONFIG_CLEAN)
for d in $(ALL_DEPDIRS); do \
if test -d "$$d"; then rmdir "$$d" || exit 1; fi; \
done
+ if test "$(srcdir)" != "."; then \
+ rm -f $(STALE_GENERATED_FILES); \
+ fi
# This used to depend on c-exp.c m2-exp.c TAGS
# I believe this is wrong; the makefile standards for distclean just
--
2.55.0
next prev parent reply other threads:[~2026-09-05 4:26 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-05 4:23 [PATCH v2 00/19] Move C++ support code out of .y files simon.marchi
2026-09-05 4:23 ` [PATCH v2 01/19] gdb/ada-exp-parser: remove name_info struct simon.marchi
2026-09-05 4:23 ` [PATCH v2 02/19] gdb: replace parse_type macros with functions simon.marchi
2026-09-05 4:23 ` [PATCH v2 03/19] gdb: suffix flex/bison output files with -gen.c simon.marchi
2026-09-05 4:23 ` [PATCH v2 04/19] gdb: remove YY_NULL to YY_NULLPTR substitution simon.marchi
2026-09-05 4:23 ` [PATCH v2 05/19] gdb: move parser output post-processing to a script simon.marchi
2026-09-05 4:23 ` [PATCH v2 06/19] gdb: let the parser and lexer generators prefix their symbols simon.marchi
2026-09-05 4:23 ` [PATCH v2 07/19] gdb: separate cp-name-parser's symbol prefix with an underscore simon.marchi
2026-09-05 4:23 ` [PATCH v2 08/19] gdb: make $(YACC) and $(FLEX) generate headers simon.marchi
2026-09-05 4:23 ` simon.marchi [this message]
2026-09-05 4:23 ` [PATCH v2 10/19] gdb: move cp-name-parser.y's support code to cp-name-parser.c simon.marchi
2026-09-05 4:23 ` [PATCH v2 11/19] gdb: rename LANG-exp.y to LANG-exp-parser.y simon.marchi
2026-09-05 4:23 ` [PATCH v2 12/19] gdb: move c-exp-parser.y's support code to c-exp-parser.c simon.marchi
2026-09-05 4:23 ` [PATCH v2 13/19] gdb: move ada-exp-parser.y's support code to ada-exp-parser.c simon.marchi
2026-09-08 18:28 ` Kevin Buettner
2026-09-05 4:23 ` [PATCH v2 14/19] gdb: move d-exp-parser.y's support code to d-exp-parser.c simon.marchi
2026-09-05 4:23 ` [PATCH v2 15/19] gdb: move f-exp-parser.y's support code to f-exp-parser.c simon.marchi
2026-09-05 4:23 ` [PATCH v2 16/19] gdb: move go-exp-parser.y's support code to go-exp-parser.c simon.marchi
2026-09-05 4:23 ` [PATCH v2 17/19] gdb: move m2-exp-parser.y's support code to m2-exp-parser.c simon.marchi
2026-09-05 4:23 ` [PATCH v2 18/19] gdb: move p-exp-parser.y's support code to p-exp-parser.c simon.marchi
2026-09-05 4:23 ` [PATCH v2 19/19] gdb: honor "set debug parser" in the Modula-2 and Pascal parsers simon.marchi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260905042353.1702204-10-simon.marchi@polymtl.ca \
--to=simon.marchi@polymtl.ca \
--cc=gdb-patches@sourceware.org \
--cc=simon.marchi@efficios.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox