MESSAGE
| DATE | 2021-01-25 |
| FROM | Paul Smith
|
| SUBJECT | Re: [Hangout - NYLXS] Future plans for Autotools
|
From hangout-bounces-at-nylxs.com Mon Jan 25 17:31:06 2021
Return-Path:
X-Original-To: archive-at-mrbrklyn.com
Delivered-To: archive-at-mrbrklyn.com
Received: from www2.mrbrklyn.com (www2.mrbrklyn.com [96.57.23.82])
by mrbrklyn.com (Postfix) with ESMTP id 13403164000;
Mon, 25 Jan 2021 17:31:06 -0500 (EST)
X-Original-To: hangout-at-www2.mrbrklyn.com
Delivered-To: hangout-at-www2.mrbrklyn.com
Received: by mrbrklyn.com (Postfix, from userid 1000)
id A2D52164045; Mon, 25 Jan 2021 17:30:26 -0500 (EST)
Resent-From: Ruben Safir
Resent-Date: Mon, 25 Jan 2021 17:30:26 -0500
Resent-Message-ID: <20210125223026.GH7019-at-www2.mrbrklyn.com>
Resent-To: hangout-at-mrbrklyn.com
X-Original-To: ruben-at-mrbrklyn.com
Delivered-To: ruben-at-mrbrklyn.com
Received: from lists.gnu.org (lists.gnu.org [209.51.188.17])
by mrbrklyn.com (Postfix) with ESMTP id 2C1B0163FEE
for ; Mon, 25 Jan 2021 10:03:55 -0500 (EST)
Received: from localhost ([::1]:43056 helo=lists1p.gnu.org)
by lists.gnu.org with esmtp (Exim 4.90_1)
(envelope-from )
id 1l43PG-0005gl-V2
for ruben-at-mrbrklyn.com; Mon, 25 Jan 2021 10:03:54 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:45326)
by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from ) id 1l43P4-0005gQ-Mv
for autoconf-at-gnu.org; Mon, 25 Jan 2021 10:03:42 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e]:51874)
by eggs.gnu.org with esmtp (Exim 4.90_1)
(envelope-from ) id 1l43P4-0002xT-GU
for autoconf-at-gnu.org; Mon, 25 Jan 2021 10:03:42 -0500
Received: from pool-96-233-64-159.bstnma.fios.verizon.net
([96.233.64.159]:37236 helo=pdslaptop.home)
by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
(Exim 4.82) (envelope-from ) id 1l43P3-0008QJ-Qn
for autoconf-at-gnu.org; Mon, 25 Jan 2021 10:03:42 -0500
Message-ID: <5de527bec7ff55bdcd285799b13c2887dce5aed1.camel-at-gnu.org>
From: Paul Smith
To: Autoconf
Date: Mon, 25 Jan 2021 10:03:40 -0500
In-Reply-To:
References:
<87zh12osjk.fsf-at-tromey.com>
<87eei97w7a.fsf-at-tromey.com>
<25f02fe5254319a29cde8215893450fc0e0850f7.camel-at-gnu.org>
Organization: GNU's Not UNIX!
User-Agent: Evolution 3.36.4-0ubuntu1
MIME-Version: 1.0
X-BeenThere: autoconf-at-gnu.org
X-Mailman-Version: 2.1.23
Precedence: list
Subject: Re: [Hangout - NYLXS] Future plans for Autotools
X-BeenThere: hangout-at-nylxs.com
List-Id: NYLXS Tech Talk and Politics
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
Reply-To: psmith-at-gnu.org
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: hangout-bounces-at-nylxs.com
Sender: "Hangout"
On Mon, 2021-01-25 at 09:47 -0500, Zack Weinberg wrote:
> I'm not at all familiar with Automake's internals, but the reason I
> suggested taking advantage of GNU make extensions was the potential
> for _complexity_ reduction of the generated Makefile, not
> performance.
Oh yes, there's absolutely no question that generated makefiles could
be made significantly simpler if we didn't have to write them as POSIX-
compliant, and could rely on some GNU make features. The POSIX spec
for make is pretty limited/limiting.
I only meant to suggest I don't think performance will be much
different.
Your example squarely fits within my thought that if the automake devs
feel that requiring GNU make would make their lives simpler, that would
be a good reason to require it.
> Automake _does_ make heavy use of shell constructs embedded inside
> frequently-executed rules, for instance
Oh interesting. Yes, I agree, a good bit of shell-based pathname
manipulation could be tossed, if not all, and that could make a
difference. Especially on platforms like Windows where process startup
is far more expensive.
_______________________________________________
Hangout mailing list
Hangout-at-nylxs.com
http://lists.mrbrklyn.com/mailman/listinfo/hangout
|
|
