diff mbox

[RFC] Update minimum make version to 3.81

Message ID 9be74649-8a90-1023-df39-a319b6d85b74@linux.vnet.ibm.com
State Rejected
Delegated to: Roland McGrath
Headers

Commit Message

Paul E. Murphy June 10, 2016, 10:17 p.m. UTC 
  This would bump the project from 3.79 to 3.81.  The primary
motivation is to enable usage of the eval function.  3.81
was released in 2006.

	* configure.ac: Update minimum make version to 3.81.
	* configure: Regenerate
	* INSTALL: Update comments about minimum make version.
	* manual/install.texti: Likewise.
---
 INSTALL             | 4 ++--
 configure           | 2 +-
 configure.ac        | 2 +-
 manual/install.texi | 4 ++--
 4 files changed, 6 insertions(+), 6 deletions(-)

Comments

Roland McGrath June 10, 2016, 10:27 p.m. UTC | #1 
eval is a pretty horrible feature and I'd probably object to introducing
any uses of it into libc's makefiles.  We already have lots of things that
might have been done that way, but are instead done with generated makefiles.
Joseph Myers June 10, 2016, 10:44 p.m. UTC | #2 
On Fri, 10 Jun 2016, Paul E. Murphy wrote:

> 	* configure.ac: Update minimum make version to 3.81.
> 	* configure: Regenerate
> 	* INSTALL: Update comments about minimum make version.
> 	* manual/install.texti: Likewise.

INSTALL is a generated file.  You modify install.texi then regenerate 
INSTALL.
Mike Frysinger June 10, 2016, 11:10 p.m. UTC | #3 
On 10 Jun 2016 15:27, Roland McGrath wrote:
> eval is a pretty horrible feature and I'd probably object to introducing
> any uses of it into libc's makefiles.  We already have lots of things that
> might have been done that way, but are instead done with generated makefiles.

while i agree, i still think we should raise the min make ver.
practically speaking, no one is testing 3.79 or 3.80.

i wouldn't mind 3.82 myself -- that's 2010.  our gcc & binutils
requirements are more recent than that.
-mike
Joseph Myers June 10, 2016, 11:25 p.m. UTC | #4 
On Fri, 10 Jun 2016, Mike Frysinger wrote:

> On 10 Jun 2016 15:27, Roland McGrath wrote:
> > eval is a pretty horrible feature and I'd probably object to introducing
> > any uses of it into libc's makefiles.  We already have lots of things that
> > might have been done that way, but are instead done with generated makefiles.
> 
> while i agree, i still think we should raise the min make ver.
> practically speaking, no one is testing 3.79 or 3.80.
> 
> i wouldn't mind 3.82 myself -- that's 2010.  our gcc & binutils
> requirements are more recent than that.

It took a long time for GNU/Linux distributors to move on from 3.81.  For 
example, Ubuntu 14.04 uses 3.81.
Paul E. Murphy June 14, 2016, 8:44 p.m. UTC | #5 
On 06/10/2016 06:25 PM, Joseph Myers wrote:
> On Fri, 10 Jun 2016, Mike Frysinger wrote:
> 
>> On 10 Jun 2016 15:27, Roland McGrath wrote:
>>> eval is a pretty horrible feature and I'd probably object to introducing
>>> any uses of it into libc's makefiles.  We already have lots of things that
>>> might have been done that way, but are instead done with generated makefiles.
>>
>> while i agree, i still think we should raise the min make ver.
>> practically speaking, no one is testing 3.79 or 3.80.
>>
>> i wouldn't mind 3.82 myself -- that's 2010.  our gcc & binutils
>> requirements are more recent than that.
> 
> It took a long time for GNU/Linux distributors to move on from 3.81.  For 
> example, Ubuntu 14.04 uses 3.81.
> 

With a little more elbow grease, I no longer have reason to
raise this requirement.

Are there any other compelling reasons to pursue a bump?
Carlos O'Donell June 15, 2016, 9:01 p.m. UTC | #6 
On 06/14/2016 04:44 PM, Paul E. Murphy wrote:
> 
> 
> On 06/10/2016 06:25 PM, Joseph Myers wrote:
>> On Fri, 10 Jun 2016, Mike Frysinger wrote:
>>
>>> On 10 Jun 2016 15:27, Roland McGrath wrote:
>>>> eval is a pretty horrible feature and I'd probably object to introducing
>>>> any uses of it into libc's makefiles.  We already have lots of things that
>>>> might have been done that way, but are instead done with generated makefiles.
>>>
>>> while i agree, i still think we should raise the min make ver.
>>> practically speaking, no one is testing 3.79 or 3.80.
>>>
>>> i wouldn't mind 3.82 myself -- that's 2010.  our gcc & binutils
>>> requirements are more recent than that.
>>
>> It took a long time for GNU/Linux distributors to move on from 3.81.  For 
>> example, Ubuntu 14.04 uses 3.81.
>>
> 
> With a little more elbow grease, I no longer have reason to
> raise this requirement.
> 
> Are there any other compelling reasons to pursue a bump?
 
The only reason would be to reflect reality.

That everyone is using make 3.81 or newer.

That isn't a compelling reason though.
Florian Weimer June 24, 2016, 11:24 a.m. UTC | #7 
On 06/11/2016 12:27 AM, Roland McGrath wrote:
> eval is a pretty horrible feature and I'd probably object to introducing
> any uses of it into libc's makefiles.  We already have lots of things that
> might have been done that way, but are instead done with generated makefiles.

I would like to put this into malloc/Makefile:

$(foreach t,$(tests),$(eval CFLAGS-$t.c += -DTEST_NO_MALLOPT))

What's the alternative for adding a -D flag to every test compilation in 
a subdirectory?

Thanks,
Florian
Mike Frysinger June 24, 2016, 4:10 p.m. UTC | #8 
On 24 Jun 2016 13:24, Florian Weimer wrote:
> On 06/11/2016 12:27 AM, Roland McGrath wrote:
> > eval is a pretty horrible feature and I'd probably object to introducing
> > any uses of it into libc's makefiles.  We already have lots of things that
> > might have been done that way, but are instead done with generated makefiles.
> 
> I would like to put this into malloc/Makefile:
> 
> $(foreach t,$(tests),$(eval CFLAGS-$t.c += -DTEST_NO_MALLOPT))
> 
> What's the alternative for adding a -D flag to every test compilation in 
> a subdirectory?

maybe something like (untested):
CPPFLAGS += $(if $(filter $(@F),$(tests)),-DTEST_NO_MALLOPT)
-mike
Florian Weimer June 24, 2016, 4:31 p.m. UTC | #9 
On 06/24/2016 06:10 PM, Mike Frysinger wrote:
> On 24 Jun 2016 13:24, Florian Weimer wrote:
>> On 06/11/2016 12:27 AM, Roland McGrath wrote:
>>> eval is a pretty horrible feature and I'd probably object to introducing
>>> any uses of it into libc's makefiles.  We already have lots of things that
>>> might have been done that way, but are instead done with generated makefiles.
>>
>> I would like to put this into malloc/Makefile:
>>
>> $(foreach t,$(tests),$(eval CFLAGS-$t.c += -DTEST_NO_MALLOPT))
>>
>> What's the alternative for adding a -D flag to every test compilation in
>> a subdirectory?
>
> maybe something like (untested):
> CPPFLAGS += $(if $(filter $(@F),$(tests)),-DTEST_NO_MALLOPT)

Hmm, right.  It's relying on the delayed expansion.  Not sure how this 
is less evil, though.  It also has at least quadratic run-time behavior.

Thanks,
Florian
Paul E. Murphy June 24, 2016, 5:15 p.m. UTC | #10 
On 06/24/2016 11:31 AM, Florian Weimer wrote:
> On 06/24/2016 06:10 PM, Mike Frysinger wrote:
>> On 24 Jun 2016 13:24, Florian Weimer wrote:
>>> On 06/11/2016 12:27 AM, Roland McGrath wrote:
>>>> eval is a pretty horrible feature and I'd probably object to introducing
>>>> any uses of it into libc's makefiles.  We already have lots of things that
>>>> might have been done that way, but are instead done with generated makefiles.
>>>
>>> I would like to put this into malloc/Makefile:
>>>
>>> $(foreach t,$(tests),$(eval CFLAGS-$t.c += -DTEST_NO_MALLOPT))
>>>
>>> What's the alternative for adding a -D flag to every test compilation in
>>> a subdirectory?
>>
>> maybe something like (untested):
>> CPPFLAGS += $(if $(filter $(@F),$(tests)),-DTEST_NO_MALLOPT)
> 
> Hmm, right.  It's relying on the delayed expansion.  Not sure how this is less evil, though.  It also has at least quadratic run-time behavior.
> 
> Thanks,
> Florian
> 

That seems like an undesirable precedent to set.
What about target specific variable updates on
the object files?

I attempted a similar thing in my current set
of patches to libm.

i.e (also untested):

$(foreach,s,$(all-object-suffixes),$(addsuffix,$(s),$(tests))): CPPFLAGS += -DTEST_NO_MALLOPT

IMO, eval still seems like the least bad option.
Mike Frysinger June 24, 2016, 5:49 p.m. UTC | #11 
On 24 Jun 2016 18:31, Florian Weimer wrote:
> On 06/24/2016 06:10 PM, Mike Frysinger wrote:
> > On 24 Jun 2016 13:24, Florian Weimer wrote:
> >> On 06/11/2016 12:27 AM, Roland McGrath wrote:
> >>> eval is a pretty horrible feature and I'd probably object to introducing
> >>> any uses of it into libc's makefiles.  We already have lots of things that
> >>> might have been done that way, but are instead done with generated makefiles.
> >>
> >> I would like to put this into malloc/Makefile:
> >>
> >> $(foreach t,$(tests),$(eval CFLAGS-$t.c += -DTEST_NO_MALLOPT))
> >>
> >> What's the alternative for adding a -D flag to every test compilation in
> >> a subdirectory?
> >
> > maybe something like (untested):
> > CPPFLAGS += $(if $(filter $(@F),$(tests)),-DTEST_NO_MALLOPT)
> 
> Hmm, right.  It's relying on the delayed expansion.  Not sure how this 
> is less evil, though.  It also has at least quadratic run-time behavior.

what about using target-specific variables and relying on inheritance [1] ?
does this work ?
$(tests): CPPFLAGS += ...

[1] https://www.gnu.org/software/make/manual/html_node/Target_002dspecific.html
-mike
Florian Weimer June 24, 2016, 6:01 p.m. UTC | #12 
On 06/24/2016 07:49 PM, Mike Frysinger wrote:
> On 24 Jun 2016 18:31, Florian Weimer wrote:
>> On 06/24/2016 06:10 PM, Mike Frysinger wrote:
>>> On 24 Jun 2016 13:24, Florian Weimer wrote:
>>>> On 06/11/2016 12:27 AM, Roland McGrath wrote:
>>>>> eval is a pretty horrible feature and I'd probably object to introducing
>>>>> any uses of it into libc's makefiles.  We already have lots of things that
>>>>> might have been done that way, but are instead done with generated makefiles.
>>>>
>>>> I would like to put this into malloc/Makefile:
>>>>
>>>> $(foreach t,$(tests),$(eval CFLAGS-$t.c += -DTEST_NO_MALLOPT))
>>>>
>>>> What's the alternative for adding a -D flag to every test compilation in
>>>> a subdirectory?
>>>
>>> maybe something like (untested):
>>> CPPFLAGS += $(if $(filter $(@F),$(tests)),-DTEST_NO_MALLOPT)
>>
>> Hmm, right.  It's relying on the delayed expansion.  Not sure how this
>> is less evil, though.  It also has at least quadratic run-time behavior.
>
> what about using target-specific variables and relying on inheritance [1] ?
> does this work ?
> $(tests): CPPFLAGS += ...

It would have to be something like:

$(tests:%=$(objpfx)%.o): CPPFLAGS += -DTEST_NO_MALLOPT

I like your first suggestion better because it doesn't construct the 
full target name, so you only need to know about $(*F).

Florian
Mike Frysinger June 24, 2016, 6:46 p.m. UTC | #13 
On 24 Jun 2016 20:01, Florian Weimer wrote:
> On 06/24/2016 07:49 PM, Mike Frysinger wrote:
> > On 24 Jun 2016 18:31, Florian Weimer wrote:
> >> On 06/24/2016 06:10 PM, Mike Frysinger wrote:
> >>> On 24 Jun 2016 13:24, Florian Weimer wrote:
> >>>> On 06/11/2016 12:27 AM, Roland McGrath wrote:
> >>>>> eval is a pretty horrible feature and I'd probably object to introducing
> >>>>> any uses of it into libc's makefiles.  We already have lots of things that
> >>>>> might have been done that way, but are instead done with generated makefiles.
> >>>>
> >>>> I would like to put this into malloc/Makefile:
> >>>>
> >>>> $(foreach t,$(tests),$(eval CFLAGS-$t.c += -DTEST_NO_MALLOPT))
> >>>>
> >>>> What's the alternative for adding a -D flag to every test compilation in
> >>>> a subdirectory?
> >>>
> >>> maybe something like (untested):
> >>> CPPFLAGS += $(if $(filter $(@F),$(tests)),-DTEST_NO_MALLOPT)
> >>
> >> Hmm, right.  It's relying on the delayed expansion.  Not sure how this
> >> is less evil, though.  It also has at least quadratic run-time behavior.
> >
> > what about using target-specific variables and relying on inheritance [1] ?
> > does this work ?
> > $(tests): CPPFLAGS += ...
> 
> It would have to be something like:
> 
> $(tests:%=$(objpfx)%.o): CPPFLAGS += -DTEST_NO_MALLOPT

did you verify that ?  target-specific variables inherit across targets.

example:
$ cat Makefile
tests = a
check: $(tests)
$(tests): CPPFLAGS += FOO
a: a.o
a.o:
	echo $(CPPFLAGS)
	false

$ make
echo FOO
FOO
...
-mike
Florian Weimer June 24, 2016, 8:11 p.m. UTC | #14 
On 06/24/2016 08:46 PM, Mike Frysinger wrote:

>>> what about using target-specific variables and relying on inheritance [1] ?
>>> does this work ?
>>> $(tests): CPPFLAGS += ...
>>
>> It would have to be something like:
>>
>> $(tests:%=$(objpfx)%.o): CPPFLAGS += -DTEST_NO_MALLOPT
>
> did you verify that ?  target-specific variables inherit across targets.
>
> example:
> $ cat Makefile
> tests = a
> check: $(tests)
> $(tests): CPPFLAGS += FOO
> a: a.o
> a.o:
> 	echo $(CPPFLAGS)
> 	false
>
> $ make
> echo FOO
> FOO
> ...

Oh wow.  It does work (even with make 3.81).

But how is this a good idea?  It means that if a target match %.o is 
built not via $(tests), but as a prerequisite of another target, the 
variable is not applied (and the target is not rebuilt for the other 
dependency chain, I assume).

I suppose it's unlikely that developers will try to rebuild individual 
.o files in subdirectories.  But my, what an obscure make feature!

Florian
Mike Frysinger June 24, 2016, 8:50 p.m. UTC | #15 
On 24 Jun 2016 22:11, Florian Weimer wrote:
> On 06/24/2016 08:46 PM, Mike Frysinger wrote:
> >>> what about using target-specific variables and relying on inheritance [1] ?
> >>> does this work ?
> >>> $(tests): CPPFLAGS += ...
> >>
> >> It would have to be something like:
> >>
> >> $(tests:%=$(objpfx)%.o): CPPFLAGS += -DTEST_NO_MALLOPT
> >
> > did you verify that ?  target-specific variables inherit across targets.
> >
> > example:
> > $ cat Makefile
> > tests = a
> > check: $(tests)
> > $(tests): CPPFLAGS += FOO
> > a: a.o
> > a.o:
> > 	echo $(CPPFLAGS)
> > 	false
> >
> > $ make
> > echo FOO
> > FOO
> > ...
> 
> Oh wow.  It does work (even with make 3.81).
> 
> But how is this a good idea?  It means that if a target match %.o is 
> built not via $(tests), but as a prerequisite of another target, the 
> variable is not applied (and the target is not rebuilt for the other 
> dependency chain, I assume).

that might be the case, as well as the other way around: if a lib
is rebuilt via the tests dep, it'll have that flag added.

i'm ambivalent with either solution, so whichever you feel better
about.

> I suppose it's unlikely that developers will try to rebuild individual 
> .o files in subdirectories.  But my, what an obscure make feature!

yeah, it's bitten me in the past :).
-mike
Florian Weimer June 28, 2016, 1:33 p.m. UTC | #16 
On 06/24/2016 10:50 PM, Mike Frysinger wrote:
> On 24 Jun 2016 22:11, Florian Weimer wrote:
>> On 06/24/2016 08:46 PM, Mike Frysinger wrote:
>>>>> what about using target-specific variables and relying on inheritance [1] ?
>>>>> does this work ?
>>>>> $(tests): CPPFLAGS += ...
>>>>
>>>> It would have to be something like:
>>>>
>>>> $(tests:%=$(objpfx)%.o): CPPFLAGS += -DTEST_NO_MALLOPT
>>>
>>> did you verify that ?  target-specific variables inherit across targets.
>>>
>>> example:
>>> $ cat Makefile
>>> tests = a
>>> check: $(tests)
>>> $(tests): CPPFLAGS += FOO
>>> a: a.o
>>> a.o:
>>> 	echo $(CPPFLAGS)
>>> 	false
>>>
>>> $ make
>>> echo FOO
>>> FOO
>>> ...
>>
>> Oh wow.  It does work (even with make 3.81).
>>
>> But how is this a good idea?  It means that if a target match %.o is
>> built not via $(tests), but as a prerequisite of another target, the
>> variable is not applied (and the target is not rebuilt for the other
>> dependency chain, I assume).
>
> that might be the case, as well as the other way around: if a lib
> is rebuilt via the tests dep, it'll have that flag added.

It turns out that the targets are prefixed with $(objpfx), so I do have 
to use

$(tests:%=$(objpfx)%): CPPFLAGS += -DTEST_NO_MALLOPT

At this point, I can well add the trailing .o, to cut down the magic 
somewhat.

Thanks,
Florian
diff mbox

Patch

diff --git a/INSTALL b/INSTALL
index ec3445f..9ebd05c 100644
--- a/INSTALL
+++ b/INSTALL
@@ -343,12 +343,12 @@  Recommended Tools for Compilation
 We recommend installing the following GNU tools before attempting to
 build the GNU C Library:
 
-   * GNU 'make' 3.79 or newer
+   * GNU 'make' 3.81 or newer
 
      You need the latest version of GNU 'make'.  Modifying the GNU C
      Library to work with other 'make' programs would be so difficult
      that we recommend you port GNU 'make' instead.  *Really.*  We
-     recommend GNU 'make' version 3.79.  All earlier versions have
+     recommend GNU 'make' version 3.81.  All earlier versions have
      severe bugs or lack features.
 
    * GCC 4.7 or newer
diff --git a/configure b/configure
index 19a4829..c0d97e3 100755
--- a/configure
+++ b/configure
@@ -4555,7 +4555,7 @@  $as_echo_n "checking version of $MAKE... " >&6; }
   ac_prog_version=`$MAKE --version 2>&1 | sed -n 's/^.*GNU Make[^0-9]*\([0-9][0-9.]*\).*$/\1/p'`
   case $ac_prog_version in
     '') ac_prog_version="v. ?.??, bad"; ac_verc_fail=yes;;
-    3.79* | 3.[89]* | [4-9].* | [1-9][0-9]*)
+    3.8[1-9]* | 3.9* | [4-9].* | [1-9][0-9]*)
        ac_prog_version="$ac_prog_version, ok"; ac_verc_fail=no;;
     *) ac_prog_version="$ac_prog_version, bad"; ac_verc_fail=yes;;
 
diff --git a/configure.ac b/configure.ac
index 123f0d2..3203157 100644
--- a/configure.ac
+++ b/configure.ac
@@ -955,7 +955,7 @@  AC_CHECK_PROG_VER(LD, $LD, --version,
 AC_CHECK_TOOL_PREFIX
 AC_CHECK_PROG_VER(MAKE, gnumake gmake make, --version,
   [GNU Make[^0-9]*\([0-9][0-9.]*\)],
-  [3.79* | 3.[89]* | [4-9].* | [1-9][0-9]*], critic_missing="$critic_missing make")
+  [3.8[1-9]* | 3.9* | [4-9].* | [1-9][0-9]*], critic_missing="$critic_missing make")
 
 AC_CHECK_PROG_VER(MSGFMT, gnumsgfmt gmsgfmt msgfmt, --version,
   [GNU gettext.* \([0-9]*\.[0-9.]*\)],
diff --git a/manual/install.texi b/manual/install.texi
index 79ee45f..93037fa 100644
--- a/manual/install.texi
+++ b/manual/install.texi
@@ -385,12 +385,12 @@  build @theglibc{}:
 
 @itemize @bullet
 @item
-GNU @code{make} 3.79 or newer
+GNU @code{make} 3.81 or newer
 
 You need the latest version of GNU @code{make}.  Modifying @theglibc{}
 to work with other @code{make} programs would be so difficult that
 we recommend you port GNU @code{make} instead.  @strong{Really.}  We
-recommend GNU @code{make} version 3.79.  All earlier versions have severe
+recommend GNU @code{make} version 3.81.  All earlier versions have severe
 bugs or lack features.
 
 @item