This is the mail archive of the
mailing list for the GCC project.
[Patch]: set $(STRICT_WARN) for "build" object files
- From: "Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>
- To: gcc-patches at gcc dot gnu dot org
- Cc: zack at codesourcery dot com
- Date: Mon, 10 Jan 2005 11:12:12 -0500 (EST)
- Subject: [Patch]: set $(STRICT_WARN) for "build" object files
It seems that all the "build" object files are now placed in a
subdirectory "build/" on mainline. This confuses the warning flag
mechanism in GCC's Makefile and causes these files to be built without
$(STRICT_WARN) and we lose having "-pedantic -Wno-long-long
-Wno-variadic-macros -Wold-style-definition -Werror" for these files
in stage2 and stage3.
If I remember correctly how this hack works, in $(GCC_WARN_CFLAGS) we
rely on the @D in $($(@D)-warn) resolving to "." and therefore we pull
in the $(.-warn) make variable set above. However now @D is set to
"build" and thus the uninitialized $(build-warn) variable is obtained.
So we simply have to set $(build-warn) to fix this.
The following appears to do the trick. Bootstrapped on
i686-unknown-linux-gnu, and I visually inspected the output log to see
that the additional flags were applied to the "build" files.
Ok for mainline?
2005-01-10 Kaveh R. Ghazi <email@example.com>
* Makefile.in: Set a `build-warn' variable.
diff -rup orig/egcc-CVS20050109/gcc/Makefile.in egcc-CVS20050109/gcc/Makefile.in
--- orig/egcc-CVS20050109/gcc/Makefile.in 2005-01-05 21:21:27.000000000 -0500
+++ egcc-CVS20050109/gcc/Makefile.in 2005-01-10 10:36:09.000000000 -0500
@@ -184,6 +184,7 @@ VALGRIND_DRIVER_DEFINES = @valgrind_path
# This is how we control whether or not the additional warnings are applied.
.-warn = $(STRICT_WARN)
+build-warn = $(STRICT_WARN)
GCC_WARN_CFLAGS = $(LOOSE_WARN) $($(@D)-warn) $(NOCOMMON_FLAG) $($@-warn)
# These files are to have -Werror bypassed in stage2: