bug-gnulib@gnu.org mirror (unofficial)
 help / color / mirror / Atom feed
From: Bruno Haible <bruno@clisp.org>
To: Paul Eggert <eggert@cs.ucla.edu>
Cc: bug-gnulib@gnu.org
Subject: Re: gl_SILENT
Date: Sat, 19 Sep 2020 02:25:38 +0200	[thread overview]
Message-ID: <1935169.j6soZZGZK5@omega> (raw)
In-Reply-To: <0acc1dcf-019e-221c-b4c6-002f9b87fd39@cs.ucla.edu>

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  <bruno@clisp.org>

	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.



  reply	other threads:[~2020-09-19  0:26 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <m2imce1gpu.fsf@meyering.net>
     [not found] ` <CAH8yC8n4tmO6__C=zP0JZRmc5_ddg7L6uGAuLfjV_Bm+i3oYsA@mail.gmail.com>
2020-09-17 18:23   ` [platform-testers] new snapshot available: grep-3.4-almost.19-ff30 Paul Eggert
2020-09-17 20:53 ` grep-3.4-almost.19-ff30 on Solaris 10 Bruno Haible
2020-09-18  2:26   ` Paul Eggert
2020-09-18  9:01     ` Bruno Haible
2020-09-18 16:06       ` Paul Eggert
2020-09-19  0:25         ` Bruno Haible [this message]
2020-09-17 21:07 ` [platform-testers] new snapshot available: grep-3.4-almost.19-ff30 Jeffrey Walton
2020-09-18 17:36   ` Paul Eggert
     [not found] ` <CAH8yC8mn1YMN+fgzJBKEk9+y0qTqfO2zHbWUyO2ekVq-PimX3Q@mail.gmail.com>
2020-09-17 14:40   ` Jim Meyering
2020-09-17 22:46   ` Bruno Haible
2020-09-19 13:12   ` Bruno Haible
2020-09-19 14:21     ` Jeffrey Walton
2020-09-19 19:15       ` Bruno Haible
2020-09-20 19:28     ` Bruno Haible

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.gnu.org/mailman/listinfo/bug-gnulib

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1935169.j6soZZGZK5@omega \
    --to=bruno@clisp.org \
    --cc=bug-gnulib@gnu.org \
    --cc=eggert@cs.ucla.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).