diff mbox series

Should we require GNU make in binutils?

Message ID ZOgesf+pTitJDdSN@squeak.grove.modra.org
State Accepted
Headers
Series Should we require GNU make in binutils? |

Checks

Context Check Description
snail/binutils-gdb-check success Github commit url

Commit Message

Alan Modra Aug. 25, 2023, 3:23 a.m. UTC 
  I see the toplevel Makefile.in makes use of $(filter-out ..) and other
GNU Make extensions, and requires GNU Make 3.80 or later when building
gcc.  gdb also uses GNU make extensions.  It seems silly to me that
binutils is still trying to avoid GNU make extensions.

We could start with the following (originally from Hans-Peter) which
avoids a whole lot of entering/leaving messages when building with
--enable-targets=all.  What do people think?

Comments

Fangrui Song Aug. 25, 2023, 5:12 a.m. UTC | #1 
On Thu, Aug 24, 2023 at 8:23 PM Alan Modra via Binutils
<binutils@sourceware.org> wrote:
>
> I see the toplevel Makefile.in makes use of $(filter-out ..) and other
> GNU Make extensions, and requires GNU Make 3.80 or later when building
> gcc.  gdb also uses GNU make extensions.  It seems silly to me that
> binutils is still trying to avoid GNU make extensions.
>
> We could start with the following (originally from Hans-Peter) which
> avoids a whole lot of entering/leaving messages when building with
> --enable-targets=all.  What do people think?

This is a good idea!
Jan Beulich Aug. 25, 2023, 8:15 a.m. UTC | #2 
On 25.08.2023 05:23, Alan Modra via Binutils wrote:
> I see the toplevel Makefile.in makes use of $(filter-out ..) and other
> GNU Make extensions, and requires GNU Make 3.80 or later when building
> gcc.  gdb also uses GNU make extensions.  It seems silly to me that
> binutils is still trying to avoid GNU make extensions.

Aren't pattern rules a GNU extension as well? We're already using them
in e.g. bfd/Makefile.

Jan
Jose E. Marchesi Aug. 25, 2023, 8:37 a.m. UTC | #3 
> I see the toplevel Makefile.in makes use of $(filter-out ..) and other
> GNU Make extensions, and requires GNU Make 3.80 or later when building
> gcc.  gdb also uses GNU make extensions.  It seems silly to me that
> binutils is still trying to avoid GNU make extensions.

+1
Alan Modra Aug. 25, 2023, 9:26 a.m. UTC | #4 
On Fri, Aug 25, 2023 at 10:15:33AM +0200, Jan Beulich wrote:
> On 25.08.2023 05:23, Alan Modra via Binutils wrote:
> > I see the toplevel Makefile.in makes use of $(filter-out ..) and other
> > GNU Make extensions, and requires GNU Make 3.80 or later when building
> > gcc.  gdb also uses GNU make extensions.  It seems silly to me that
> > binutils is still trying to avoid GNU make extensions.
> 
> Aren't pattern rules a GNU extension as well? We're already using them
> in e.g. bfd/Makefile.

Yes, came in with commit bd32be01c997, Jan 2022.  OK, I'll commit the
ld change too.
diff mbox series

Patch

diff --git a/ld/Makefile.am b/ld/Makefile.am
index be456275748..fcb93060a14 100644
--- a/ld/Makefile.am
+++ b/ld/Makefile.am
@@ -633,19 +633,10 @@  GEN_DEPENDS = $(srcdir)/genscripts.sh stringify.sed
 
 @TDIRS@
 
-# We can't use pattern rules as we don't want to depend on GNU
-# make, or else these rules could have been expressed in one
-# two-liner: 'e%.c:' and '	${GENSCRIPTS} $* "$(tdir_$*)"'.
-# (The recursive variable expansion is portable.)
-
-run-genscripts:
-	$(AM_V_at)${GENSCRIPTS} $(script_target) "$($(script_tdirname))"
-
-.PHONY: run-genscripts
+e%.c:
+	$(AM_V_GEN)${GENSCRIPTS} $* "$(tdir_$*)"
 
 $(ALL_EMULATION_SOURCES) $(ALL_64_EMULATION_SOURCES): $(GEN_DEPENDS)
-	$(AM_V_GEN)base=`echo $@ | sed -e 's,e\(.*\).c,\1,'`; \
-	$(MAKE) run-genscripts "script_target=$$base" "script_tdirname=tdir_$$base"
 
 # It's a pity we can't generate these include "./deps/e*.Pc" lines
 # from ALL_EMULATION_SOURCES and ALL_64_EMULATION_SOURCES, but that isn't