From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6127 invoked by alias); 27 Apr 2011 06:08:57 -0000 Received: (qmail 6117 invoked by uid 22791); 27 Apr 2011 06:08:56 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE X-Spam-Check-By: sourceware.org Received: from mailout-de.gmx.net (HELO mailout-de.gmx.net) (213.165.64.23) by sourceware.org (qpsmtpd/0.43rc1) with SMTP; Wed, 27 Apr 2011 06:08:34 +0000 Received: (qmail invoked by alias); 27 Apr 2011 06:08:32 -0000 Received: from xdsl-89-0-68-206.netcologne.de (EHLO localhost.localdomain) [89.0.68.206] by mail.gmx.net (mp071) with SMTP; 27 Apr 2011 08:08:32 +0200 Received: from ralf by localhost.localdomain with local (Exim 4.72) (envelope-from ) id 1QExvM-0004oq-9T; Wed, 27 Apr 2011 08:08:32 +0200 Date: Wed, 27 Apr 2011 06:08:00 -0000 From: Ralf Wildenhues To: Ian Lance Taylor Cc: kevin diggs , Steffen Dettmer , binutils@sourceware.org Subject: Re: binutils prerequisites (recent zlib version - what else?) Message-ID: <20110427060832.GA17569@gmx.de> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2010-08-04) X-IsSubscribed: yes Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2011-04/txt/msg00395.txt.bz2 Hello, * Ian Lance Taylor wrote on Tue, Apr 26, 2011 at 08:18:58PM CEST: > kevin diggs writes: > > Why? Wouldn't it be better to tell the poor, confused user that they > > are configuring up the wrong tree? So that we can go RTFM and get the > > right option (or whine and complain if the desired functionality does > > not exist)? > > It would be better in some cases, yes. However, the gcc and binutils > trees are examples where there is a master configure script at the top > which invokes a range of sub-configure scripts below. To make that > work, the master configure script needs to pass all --with and --enable > options to the sub-configure scripts. If configure scripts reject > unrecognized options, then it would be necessary for every configure > script to recognize every option. Since the sub-projects are maintained > by different groups of people, that is infeasible. > > To avoid the problem there is, yes, an option: --enable-option-checking. > It's sort of pathetic to have an option for option checking, since most > people aren't going to be aware of it, but it's the best we have at the > moment. The option checking option is enabled by default unless the configure script uses AC_CONFIG_SUBDIRS or AC_DISABLE_OPTION_CHECKING. Which is arguably a simple yet often encountered setup (and the disabling is done to avoid false warnings as you described). So, at least patheticness is sort of limited. ;-) Cheers, Ralf