From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4167 invoked by alias); 23 Feb 2002 04:46:04 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 4020 invoked from network); 23 Feb 2002 04:45:57 -0000 Received: from unknown (HELO cygnus.com) (205.180.230.5) by sources.redhat.com with SMTP; 23 Feb 2002 04:45:57 -0000 Received: from cse.cygnus.com (cse.cygnus.com [205.180.230.236]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id UAA19445; Fri, 22 Feb 2002 20:45:50 -0800 (PST) Received: from free.redhat.lsd.ic.unicamp.br (vpnuser.sfbay.redhat.com [10.255.17.131] (may be forged)) by cse.cygnus.com (8.8.8+Sun/8.6.4) with ESMTP id UAA18829; Fri, 22 Feb 2002 20:45:47 -0800 (PST) Received: (from aoliva@localhost) by free.redhat.lsd.ic.unicamp.br (8.11.6/8.11.6) id g1N4jjb00402; Sat, 23 Feb 2002 01:45:45 -0300 To: Brad Lucier Cc: gcc@gcc.gnu.org Subject: Re: 3.0.4 builds for solaris 2.7 and 2.8 References: <200202230437.g1N4bPj07398@banach.math.purdue.edu> From: Alexandre Oliva Organization: GCC Team, Red Hat Date: Fri, 22 Feb 2002 20:47:00 -0000 In-Reply-To: Brad Lucier's message of "Fri, 22 Feb 2002 23:37:23 -0500 (EST)" Message-ID: User-Agent: Gnus/5.0805 (Gnus v5.8.5) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-02/txt/msg01368.txt.bz2 On Feb 23, 2002, Brad Lucier wrote: > OK, how about a warning from the top-level configure for options it > can't recognize? It would be a maintenance burden to whoever modifies any of the sub-packages' set of supported options. The whole point of --with/--without and --enable/--disable flags in configure is that it's open-ended, such that you can use the same set of flags for any packages you build (unless they happen to use the same flag for totally different purposes), such that you can create a single wrapper configure script (like the one in gcc) that passes the same flags to all of the sub-packages without being concerned with their meaning. It's up to each package to interpret the flags it recognizes and ignore those that it doesn't. That said, I'll give you that the set of configure options accepted by each sub-package doesn't change very often, so it wouldn't be that much of a maintenance burden. So I wouldn't oppose a patch that implemented the feature you suggest. However, such patch wouldn't life very long, since we have a volunteer autoconfiscating the top-level configure script. -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{cygnus.com, redhat.com} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist Professional serial bug killer