From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13790 invoked by alias); 30 May 2002 23:37:55 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 13772 invoked from network); 30 May 2002 23:37:53 -0000 Received: from unknown (HELO nerodeguest) (24.161.107.98) by sources.redhat.com with SMTP; 30 May 2002 23:37:53 -0000 Received: from neroden by nerodeguest with local (Exim 3.35 #1 (Debian)) id 17DZUA-0004wd-00; Thu, 30 May 2002 19:37:38 -0400 Date: Thu, 30 May 2002 17:31:00 -0000 To: dj@redhat.com Cc: gcc-patches@gcc.gnu.org, gdb-patches@sources.redhat.com, binutils@sources.redhat.com Subject: Re: [patch] toplevel configure.in: topsrcdir->srcdir Message-ID: <20020530233738.GA18997@doctormoo.dyndns.org> References: <20020530180657.GA3212@doctormoo.dyndns.org> <200205301843.g4UIh7s21990@greed.delorie.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200205301843.g4UIh7s21990@greed.delorie.com> User-Agent: Mutt/1.3.28i From: Nathanael Nerode X-SW-Source: 2002-05/txt/msg01037.txt.bz2 On Thu, May 30, 2002 at 02:43:07PM -0400, DJ Delorie wrote: > > > This replaces references to ${topsrcdir} with ${srcdir}. This is > > correct, > > topsrcdir != srcdir when building multilibs, or any type of cross or > crossed compiler when srcdir==builddir. Have you tested any of those > configurations? 'topsrcdir' always refers to the top level directory where 'configure' is located. When 'configure.in' in the top directory is being run, srcdir is normally the same directory. In a subdirectory, srcdir and topsrcdir differ, but not at the top level. The situation where topsrcdir!=srcdir at the top level is when a 'srcdir' argument is passed to toplevel configure, and this argument is *not* the location of toplevel configure. The build system is not set up for that situation, and I expect that it breaks already. In any case, the changes I make are in fact correct, because otherwise unintuitively different behavior will result from the current code. The normal and documented scheme is that 'configure' and 'configure.in' remain in srcdir, and invoked when the current directory is builddir by something approximating `${topsrcdir}/configure`. Using this method, I had no problems with any sort of cross-compiler or cross-building. In each case $topsrcdir *was* the same as $srcdir while top level configure.in was running. (Modulo the fact that $topsrcdir is always an absolute directory reference, while $srcdir might be relative; this isn't a problem because there are no changes of directory between the setting of 'topsrcdir' and the specific uses I changed.) I'm not at all sure when "multilibs" are built and when they aren't, since multilibs are marvelously well undocumented. Is there something I'm missing, wherein toplevel 'configure' & 'configure.in' could be invoked as a subprocess rather than a top level process, and accordingly could have been copied into some other directory (which would become 'topsrcdir'), while still receiving a 'srcdir' argument of the original directory? I guess I'm saying that I don't see where the problem lies. --Nathanael