From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-Status: No, score=-4.6 required=3.0 tests=AWL,BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL, SPF_HELO_NONE,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 36CDC1F4B4 for ; Sat, 19 Sep 2020 00:26:00 +0000 (UTC) Received: from localhost ([::1]:47270 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kJQhT-0002xu-3D for normalperson@yhbt.net; Fri, 18 Sep 2020 20:25:59 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:60518) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kJQhH-0002xl-NS for bug-gnulib@gnu.org; Fri, 18 Sep 2020 20:25:48 -0400 Received: from mo4-p00-ob.smtp.rzone.de ([81.169.146.220]:15178) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kJQhD-0007dj-Qn for bug-gnulib@gnu.org; Fri, 18 Sep 2020 20:25:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1600475140; s=strato-dkim-0002; d=clisp.org; h=References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=y04nJQF/YhX0TbX0NMo0X1ADA89mFFAxVzn/mCcNYKw=; b=VlFL0nfexKMvK7AkgukxfXpFEfCpzmpBdZ3+Ry9vlVTf11kSFH1yp509RerlBEJ8Uc GnPX3r+ZLzzQk1TkhSepFNQoSxxL8t8gJguphd0dJTiPXaB9iOG72ABC2cjJQ+hZ7j7d y34YTSlVWoa3j++C3q2LmNLCaUfz8qj3OPBisp6LC0ZlkJX12zJuWdklMvNmC09BmoXM 7xEY8WRxKfukf40k5XNdiv1ts9pQgJhn0/d9+nQOM0DHMy+GtYb8kQs4cbxtzpvwdbl0 oqr+dNOsRgH8wCZ1OWNb8KQnPCBiA/tcE48p3y81P/QEQoedTVS/CVayAEZUgWXl0XNH MOig== X-RZG-AUTH: ":Ln4Re0+Ic/6oZXR1YgKryK8brlshOcZlIWs+iCP5vnk6shH+AHjwLuWOHqfyyPs=" X-RZG-CLASS-ID: mo00 Received: from bruno.haible.de by smtp.strato.de (RZmta 46.10.7 DYNA|AUTH) with ESMTPSA id z05f0fw8J0Pd66V (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (curve X9_62_prime256v1 with 256 ECDH bits, eq. 3072 bits RSA)) (Client did not present a certificate); Sat, 19 Sep 2020 02:25:39 +0200 (CEST) From: Bruno Haible To: Paul Eggert Subject: Re: gl_SILENT Date: Sat, 19 Sep 2020 02:25:38 +0200 Message-ID: <1935169.j6soZZGZK5@omega> User-Agent: KMail/5.1.3 (Linux/4.4.0-189-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: <0acc1dcf-019e-221c-b4c6-002f9b87fd39@cs.ucla.edu> References: <6160020.m44uqoBmH5@omega> <0acc1dcf-019e-221c-b4c6-002f9b87fd39@cs.ucla.edu> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Received-SPF: none client-ip=81.169.146.220; envelope-from=bruno@clisp.org; helo=mo4-p00-ob.smtp.rzone.de X-detected-operating-system: by eggs.gnu.org: First seen = 2020/09/18 20:25:41 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] [fuzzy] X-Spam_score_int: -46 X-Spam_score: -4.7 X-Spam_bar: ---- X-Spam_report: (-4.7 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.869, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_NONE=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: bug-gnulib@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Gnulib discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: bug-gnulib@gnu.org Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: "bug-gnulib" Paul Eggert wrote: > > The file descriptor 2 is unaffected by the file descriptor > > reshuffle. Only file descriptor 6 is affected, which is the one used by > > AC_MSG_CHECKING/AC_MSG_RESULT. No one is supposed to use this file descriptor > > in a 'trap' action. > > Ah, sorry, I misread it. > > >> Looking into it further, gl_SILENT is iffy as a general macro, as discarding > >> stderr could make scripts harder to debug. > > > > I disagree. I want gl_SILENT for the purpose of doing more complex checks inside > > an AC_CACHE_CHECK invocation. Without gl_SILENT, the message output dictates the > > structure of the AC_CACHE_CHECKs. This is not good. Stated differently: Currently, AC_CACHE_CHECKs cannot be nested. This forces macro authors to define the checks one after the other, with the lowest level first and the highest level last. Quite often this is reasonable and sufficient. But the fact that I invented two different mechanisms to get around it (1. pushdef/popdef of AC_MSG_CHECKING and AC_MSG_RESULT, 2. gl_SILENT) proves that it is a persistent thorn. > Agreed, but isn't gl_SILENT an unnecessarily tricky way to go about it? I worry > we'll eventually need a gl_NOISY macro to counteract the effect of gl_SILENT. If we document clearly that nested AC_CACHE_CHECKs have no output, no gl_NOISY will be needed - as macro authors can revert to the "inner check first" style. > If this approach was that useful in practice, why doesn't C's stdio package have > a function that does something similar, e.g., stdio_silent (stderr, FOO) calls > FOO and arranges for FOO's fprintf (stderr, ....) calls to have no effect? In C it is natural to introduce function parameters or static variables for this. > If the problem is that AC_CACHE_CHECK is always noisy, do we simply need a quiet > variant? Something like gl_CACHE_VAL_SILENT vs AC_CACHE_VAL? That is one possible way. We would then have gl_CACHE_CHECK_SILENT, gl_CHECK_FUNC_SILENT, gl_CHECK_HEADER_SILENT, and maybe more. > Or perhaps we > should change what Autoconf does (admittedly this is a longer-term project)? This is a longer-term project, yes. There are multiple problems for Autoconf macro authors: - You can't nest AC_CACHE_CHECK, or the configure output will be messy. - When investigating problems, I need to look at 4 files: the configure output, config.status, config.cache, and config.log. And they are partly redundant. - The configure output is so long that most people skip reading it, only WARNINGs that stay out get read. - Especially the lines with '(cached)' are useless. - A summary section that lists the external dependencies and most important details (ABI, compiler, compiler options) but not the hundreds of other test results is useful. But Autoconf has no standard macro for doing this. These problems are all somewhat related. gl_SILENT is only one brick that allows to experiment with solutions of the first problem. > If it's needed then by all means please reinstate it as needed for getaddrinfo etc. Reinstated: 2020-09-18 Bruno Haible Add back gl_SILENT. * m4/gnulib-common.m4 (GL_TMP_FD, gl_SILENT): New macros. diff --git a/m4/gnulib-common.m4 b/m4/gnulib-common.m4 index c9f8ca6..57343e4 100644 --- a/m4/gnulib-common.m4 +++ b/m4/gnulib-common.m4 @@ -1,4 +1,4 @@ -# gnulib-common.m4 serial 59 +# gnulib-common.m4 serial 60 dnl Copyright (C) 2007-2020 Free Software Foundation, Inc. dnl This file is free software; the Free Software Foundation dnl gives unlimited permission to copy and/or distribute it, @@ -630,6 +630,22 @@ AC_DEFUN([gl_BIGENDIAN], AC_C_BIGENDIAN ]) +# A temporary file descriptor. +# Must be less than 10, because dash 0.5.8 does not support redirections +# with multi-digit file descriptors. +m4_define([GL_TMP_FD], 9) + +# gl_SILENT(command) +# executes command, but without the normal configure output. +# This is useful when you want to invoke AC_CACHE_CHECK (or AC_CHECK_FUNC etc.) +# inside another AC_CACHE_CHECK. +AC_DEFUN([gl_SILENT], +[ + exec GL_TMP_FD>&AS_MESSAGE_FD AS_MESSAGE_FD>/dev/null + $1 + exec AS_MESSAGE_FD>&GL_TMP_FD GL_TMP_FD>&- +]) + # gl_CACHE_VAL_SILENT(cache-id, command-to-set-it) # is like AC_CACHE_VAL(cache-id, command-to-set-it), except that it does not # output a spurious "(cached)" mark in the midst of other configure output.