Message ID | 9be74649-8a90-1023-df39-a319b6d85b74@linux.vnet.ibm.com |
---|---|
State | Rejected |
Delegated to: | Roland McGrath |
Headers |
Received: (qmail 56307 invoked by alias); 10 Jun 2016 22:17:52 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <libc-alpha.sourceware.org> List-Unsubscribe: <mailto:libc-alpha-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/libc-alpha/> List-Post: <mailto:libc-alpha@sourceware.org> List-Help: <mailto:libc-alpha-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 56296 invoked by uid 89); 10 Jun 2016 22:17:51 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL, BAYES_00, KAM_LAZY_DOMAIN_SECURITY, RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 spammy=ld, LD, severe, 2.4.11 X-HELO: mx0a-001b2d01.pphosted.com X-IBM-Helo: d03dlp01.boulder.ibm.com X-IBM-MailFrom: murphyp@linux.vnet.ibm.com X-IBM-RcptTo: libc-alpha@sourceware.org From: "Paul E. Murphy" <murphyp@linux.vnet.ibm.com> Subject: [RFC] Update minimum make version to 3.81 To: "libc-alpha@sourceware.org" <libc-alpha@sourceware.org> Date: Fri, 10 Jun 2016 17:17:35 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16061022-0024-0000-0000-000013DB2DEB X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 16061022-0025-0000-0000-000041B262D1 Message-Id: <9be74649-8a90-1023-df39-a319b6d85b74@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-06-10_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1606100246 |
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
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.
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.
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
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.
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?
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.
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
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
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
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.
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
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
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
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
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
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 --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