Should we require GNU make in binutils?
Checks
| Context |
Check |
Description |
| linaro-tcwg-bot/tcwg_binutils_build--master-arm |
success
|
Testing passed
|
| linaro-tcwg-bot/tcwg_binutils_build--master-aarch64 |
success
|
Testing passed
|
| linaro-tcwg-bot/tcwg_binutils_check--master-aarch64 |
success
|
Testing passed
|
| linaro-tcwg-bot/tcwg_binutils_check--master-arm |
success
|
Testing passed
|
Commit Message
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
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!
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
> 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
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.
@@ -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