From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17648 invoked by alias); 17 Oct 2011 17:30:25 -0000 Received: (qmail 17638 invoked by uid 22791); 17 Oct 2011 17:30:24 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 17 Oct 2011 17:30:06 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 561662BAF13; Mon, 17 Oct 2011 13:30:05 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id WwRSWphHXQWV; Mon, 17 Oct 2011 13:30:05 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 4C1472BAF3E; Mon, 17 Oct 2011 13:30:03 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 89E55145615; Mon, 17 Oct 2011 13:30:00 -0400 (EDT) Date: Mon, 17 Oct 2011 18:23:00 -0000 From: Joel Brobecker To: Mike Frysinger Cc: gdb-patches@sourceware.org, toolchain-devel@blackfin.uclinux.org Subject: Re: [PATCH] sim: use AC_REQUIRE with AC_PROG_CC Message-ID: <20111017173000.GA19246@adacore.com> References: <1310418640-32168-1-git-send-email-vapier@gentoo.org> <20111017165724.GC17942@adacore.com> <201110171315.07219.vapier@gentoo.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201110171315.07219.vapier@gentoo.org> User-Agent: Mutt/1.5.20 (2009-06-14) Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2011-10/txt/msg00482.txt.bz2 > i don't think there is a requirement for the AC_REQUIRE to be where it is; > i'll have to double check. the reason i moved it is that the convention i've > seen when reading other GNU projects is to put unconditional AC_REQUIRE calls > at the top of m4 defines. SIM_AC_COMMON is probably a bit of a special case > though due to it mostly being the normal configure.ac file. > > i can move it back if you like (and i verify that it works fine). Nah, that's Ok. The comment right after is what prompted the question, and it is a bit misleading. I'd just remove it (as a follow up patch) I think, it doesn't bring anything anyway. -- Joel