From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-patches-return-99740-listarch-gdb-patches=sources.redhat.com@sourceware.org>
Received: (qmail 30047 invoked by alias); 21 Mar 2013 18:44:04 -0000
Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb-patches.sourceware.org>
List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb-patches/>
List-Post: <mailto:gdb-patches@sourceware.org>
List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-patches-owner@sourceware.org
Received: (qmail 29975 invoked by uid 89); 21 Mar 2013 18:43:54 -0000
X-Spam-SWARE-Status: No, score=-3.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_SOFTFAIL autolearn=no version=3.3.1
Received: from mtaout20.012.net.il (HELO mtaout20.012.net.il) (80.179.55.166)    by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Thu, 21 Mar 2013 18:43:51 +0000
Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MK000500XAUT600@a-mtaout20.012.net.il> for gdb-patches@sourceware.org; Thu, 21 Mar 2013 20:43:49 +0200 (IST)
Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MK0005VOXD08T70@a-mtaout20.012.net.il>; Thu, 21 Mar 2013 20:43:49 +0200 (IST)
Date: Thu, 21 Mar 2013 18:53:00 -0000
From: Eli Zaretskii <eliz@gnu.org>
Subject: Re: [PATCH] Display configuration details in --help
In-reply-to: <CADPb22R4o4gkQk8oeqGvmWZerVf7gdkw8XOKz9mYxD6ubFPRig@mail.gmail.com>
To: Doug Evans <dje@google.com>
Cc: gdb-patches@sourceware.org
Reply-to: Eli Zaretskii <eliz@gnu.org>
Message-id: <83y5dgy4ne.fsf@gnu.org>
References: <83r4jaynqq.fsf@gnu.org> <CADPb22R4o4gkQk8oeqGvmWZerVf7gdkw8XOKz9mYxD6ubFPRig@mail.gmail.com>
X-SW-Source: 2013-03/txt/msg00805.txt.bz2

> Date: Thu, 21 Mar 2013 10:54:44 -0700
> From: Doug Evans <dje@google.com>
> Cc: gdb-patches <gdb-patches@sourceware.org>
> 
> I like the idea, but the implementation imposes a future
> maintenance burden.

Yes, I considered that as well.  But I succeeded in convincing myself
that the problem is not that significant, because:

  . configuration options change relatively rarely

  . it is not a catastrophe if a new option is added that is not
    reflected in this output for a while (options that are removed
    will cause compilation failures, so that's not a problem)

  . a slightly outdated output is much better than nothing at all

> Would it be sufficient to just store the original string somewhere and
> print that?

I thought about that, but the problem is that most options are not
explicitly mentioned on the configure command line, they are
auto-detected by the configury.  So if we want to automate this, we
will need some configure-time magic, like create a file with these
options.