From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 55475 invoked by alias); 17 Nov 2016 20:43:03 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 55336 invoked by uid 89); 17 Nov 2016 20:43:03 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.4 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=unavailable version=3.3.2 spammy=our X-HELO: eggs.gnu.org Received: from eggs.gnu.org (HELO eggs.gnu.org) (208.118.235.92) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 17 Nov 2016 20:43:01 +0000 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c7TWN-0006wt-HE for gdb-patches@sourceware.org; Thu, 17 Nov 2016 15:43:00 -0500 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:50038) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c7TW3-0006nz-AQ; Thu, 17 Nov 2016 15:42:39 -0500 Received: from pool-173-76-103-90.bstnma.fios.verizon.net ([173.76.103.90]:52528 helo=homebase) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1c7TW2-0006Yv-T5; Thu, 17 Nov 2016 15:42:39 -0500 Message-ID: <1479415358.3489.313.camel@gnu.org> Subject: Re: Require GNU make to build binutils-gdb From: Paul Smith Reply-To: psmith@gnu.org To: Simon Marchi Cc: binutils@sourceware.org, gdb-patches@sourceware.org Date: Thu, 17 Nov 2016 20:43:00 -0000 In-Reply-To: References: <144f4f68acf24fc1084b585700c65b63@polymtl.ca> <20161117200637.GV21655@vapier.lan> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-SW-Source: 2016-11/txt/msg00500.txt.bz2 Regarding the patch linked to earlier, I wonder why multiple pattern rules were added, rather than just using VPATH plus a few pattern rules / explicit rules for the special cases? I didn't check carefully. On Thu, 2016-11-17 at 15:33 -0500, Simon Marchi wrote: > But as Andreas Schwab mentioned in our earlier discussions, there is > already such a check for gcc: > >    @if gcc >    ifeq (,$(.VARIABLES)) # The variable .VARIABLES, new with 3.80, is > never empty. >    $(error GNU make version 3.80 or newer is required.) >    endif >    @endif gcc > > Since we don't have a particular reason to want 3.81 over 3.80, we could > just re-use this check (make it unconditional), if that makes it easier. If you want to check for 3.81, you could look for the .FEATURES variable instead of .VARIABLES; .FEATURES was introduced in 3.81 and is intended to let your makefile query what features are available without worrying about specific versions. It's also never empty, if it exists. It has one nice advantage in that it's a static value, while .VARIABLES requires GNU make to create a list of the names of all the variables. But, if this check is done early that's not such a big deal. 3.81 was released 10.5 years ago (Apr 2006). > > for sim/, i have no problem having it follow gdb, although i was > > planning on converting it to automake ... > > I think that's a good thing then, automake probably plays better with > GNU make than other makes. automake, technically, generates POSIX compliant makefiles that don't rely on GNU make features at all and should work with a wide range of different make implementations. At least, that's how it is unless something has changed since I looked last.