Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: simon.marchi@polymtl.ca
To: gdb-patches@sourceware.org
Cc: Simon Marchi <simon.marchi@efficios.com>
Subject: [PATCH 08/17] gdb: add check for stale build generated files
Date: Fri,  4 Sep 2026 12:56:40 -0400	[thread overview]
Message-ID: <20260904170338.1643894-9-simon.marchi@polymtl.ca> (raw)
In-Reply-To: <20260904170338.1643894-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


  parent reply	other threads:[~2026-09-04 17:06 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-04 16:56 [PATCH 00/17] Move C++ support code out of .y files simon.marchi
2026-09-04 16:56 ` [PATCH 01/17] gdb/ada-exp-parser: remove name_info struct simon.marchi
2026-09-04 16:56 ` [PATCH 02/17] gdb: replace parse_type macros with functions simon.marchi
2026-09-04 16:56 ` [PATCH 03/17] gdb: suffix flex/bison output files with -gen.c simon.marchi
2026-09-04 16:56 ` [PATCH 04/17] gdb: move parser output post-processing to a script simon.marchi
2026-09-05  0:38   ` Kevin Buettner
2026-09-05  3:59     ` Simon Marchi
2026-09-04 16:56 ` [PATCH 05/17] gdb: let the parser and lexer generators prefix their symbols simon.marchi
2026-09-04 16:56 ` [PATCH 06/17] gdb: separate cp-name-parser's symbol prefix with an underscore simon.marchi
2026-09-04 16:56 ` [PATCH 07/17] gdb: make $(YACC) and $(FLEX) generate headers simon.marchi
2026-09-04 16:56 ` simon.marchi [this message]
2026-09-04 16:56 ` [PATCH 09/17] gdb: move cp-name-parser.y's support code to cp-name-parser.c simon.marchi
2026-09-04 16:56 ` [PATCH 10/17] gdb: rename LANG-exp.y to LANG-exp-parser.y simon.marchi
2026-09-04 16:56 ` [PATCH 11/17] gdb: move c-exp-parser.y's support code to c-exp-parser.c simon.marchi
2026-09-04 16:56 ` [PATCH 12/17] gdb: move ada-exp-parser.y's support code to ada-exp-parser.c simon.marchi
2026-09-05  0:16   ` Kevin Buettner
2026-09-04 16:56 ` [PATCH 13/17] gdb: move d-exp-parser.y's support code to d-exp-parser.c simon.marchi
2026-09-04 16:56 ` [PATCH 14/17] gdb: move f-exp-parser.y's support code to f-exp-parser.c simon.marchi
2026-09-04 16:56 ` [PATCH 15/17] gdb: move go-exp-parser.y's support code to go-exp-parser.c simon.marchi
2026-09-04 16:56 ` [PATCH 16/17] gdb: move m2-exp-parser.y's support code to m2-exp-parser.c simon.marchi
2026-09-05  0:30   ` Kevin Buettner
2026-09-05  4:04     ` Simon Marchi
2026-09-04 16:56 ` [PATCH 17/17] gdb: move p-exp-parser.y's support code to p-exp-parser.c simon.marchi
2026-09-05  0:29   ` Kevin Buettner
2026-09-05  0:50 ` [PATCH 00/17] Move C++ support code out of .y files Kevin Buettner

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=20260904170338.1643894-9-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