From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22215 invoked by alias); 6 Jan 2008 10:58:26 -0000 Received: (qmail 22201 invoked by uid 22791); 6 Jan 2008 10:58:25 -0000 X-Spam-Check-By: sourceware.org Received: from dessent.net (HELO dessent.net) (69.60.119.225) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 06 Jan 2008 10:58:04 +0000 Received: from localhost ([127.0.0.1] helo=dessent.net) by dessent.net with esmtp (Exim 4.50) id 1JBTCO-0004lM-Gx; Sun, 06 Jan 2008 10:57:48 +0000 Message-ID: <4780B42E.7D863082@dessent.net> Date: Mon, 07 Jan 2008 14:14:00 -0000 From: Brian Dessent Reply-To: gcc-help X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) MIME-Version: 1.0 To: NightStrike CC: Ian Lance Taylor , gcc-help Subject: Re: top-level configure options, --help References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org X-SW-Source: 2008-01/txt/msg00052.txt.bz2 NightStrike wrote: > If that's the case, there must be more options as well that are not > present in top level's --help that really are options that the user > would actually use. I would think that a simple AS_HELP_STRING macro > in the top level configure would accomplish this. That, or a blank > ARG_WITH macro.. something like: > > AC_ARG_WITH([sysroot], > [AS_HELP_STRING([--with-sysroot], > [Sets the sysroot])], > [], > []) > > You could list the option in the top level configure, but give it no > action. This is a benefit to the user, so that the top level > configure --help contains all the options that a user would use. That's no good. You're just duplicating stuff already in gcc/configure.ac, which means now you have two copies in two separate directories of every option to maintain, which is a real pain, and it is a recipe for things getting out of sync. I doubt any maintainer would accept this. Besides, the toplevel configure machinery is shared between a number of projects, so it really shouldn't have specific knowledge of options implemented in particular subdirs that may or may not be present in the tree. The sysroot example is perhaps not the best one because it is probably implemented by all the tools that share this file, but it is certainly not true in general. You'd end up shipping a e.g. gdb tarball that advertises meaningless configure options in its --help that don't do anything because they only apply to gcc/ or libstdc++/ or libgfortran/ or whatever dirs that aren't present in the gdb subset of the tree. The real solution is supposed to be --help=recursive which in a normal autoconf project runs the --help in the top dir and then the --help of each existing subdir's configure. But for whatever reason, this has never worked with the src/gcc toplevel configure, which is a shame because the number of options that are specific to various subdirs (i.e. not listed by the toplevel configure) is quite large. But it's simple enough just to tell users to run e.g. gcc/configure --help or libstdc++-v3/configure --help or whatever until somebody fixes --help=recursive. Brian