From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: eshell-defgroup fouls up `make bootstrap'. Date: Thu, 31 Jul 2008 17:10:13 +0000 Message-ID: <20080731171013.GC2886@muc.de> References: <20080730094830.GA3952@muc.de> <20080730220721.GA1920@muc.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1217524281 31796 80.91.229.12 (31 Jul 2008 17:11:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 31 Jul 2008 17:11:21 +0000 (UTC) Cc: Glenn Morris , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jul 31 19:12:11 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1KObhC-0003gz-66 for ged-emacs-devel@m.gmane.org; Thu, 31 Jul 2008 19:12:10 +0200 Original-Received: from localhost ([127.0.0.1]:38715 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KObgH-0001yv-A3 for ged-emacs-devel@m.gmane.org; Thu, 31 Jul 2008 13:11:13 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KObgC-0001w2-KK for emacs-devel@gnu.org; Thu, 31 Jul 2008 13:11:08 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KObgB-0001uk-Pc for emacs-devel@gnu.org; Thu, 31 Jul 2008 13:11:08 -0400 Original-Received: from [199.232.76.173] (port=42702 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KObgB-0001uJ-L0 for emacs-devel@gnu.org; Thu, 31 Jul 2008 13:11:07 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:3719 helo=mail.muc.de) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KObgB-00038F-8g for emacs-devel@gnu.org; Thu, 31 Jul 2008 13:11:07 -0400 Original-Received: (qmail 78103 invoked by uid 3782); 31 Jul 2008 17:09:33 -0000 Original-Received: from acm.muc.de (pD9E52908.dip.t-dialin.net [217.229.41.8]) by colin2.muc.de (tmda-ofmipd) with ESMTP; Thu, 31 Jul 2008 19:09:28 +0200 Original-Received: (qmail 10229 invoked by uid 1000); 31 Jul 2008 17:10:13 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Delivery-Agent: TMDA/1.1.5 (Fettercairn) X-Primary-Address: acm@muc.de X-detected-kernel: by monty-python.gnu.org: FreeBSD 4.6-4.9 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:101814 Archived-At: Hi, Stefan. First of all, sorry for the abuse in my last post. I'll get this problem sorted, somehow. On Thu, Jul 31, 2008 at 12:08:02AM -0400, Stefan Monnier wrote: > > OK. I still can't figure it out. In directory > > ~acm/emacs/emacs-300708/, the Makefile contains hard-coded > > references to ~acm/emacs/emacs/..., the wrong directory. So I need > > to rerun config. Why are we using absolute paths here rather than > > relative paths? > IIUC this is because we assume the user might be building Emacs in > another directory than where the source files are found. I don't use > that feature, but IIUC many people do. > IIUC, this is done with: > mkdir /some/builddir; cd /some/builddir; ..path/to/emacs/configure; make OK, thanks! > > So "Makefile" is one of its own targets. > It's a fairly normal behavior in systems where the Makefile is itself > built from other file(s) such as Makefile.in and config.status. > Circularity is a normal occurrence, just like the need for bootstrap. > There's no software without recursion, really. It seems in this case there's no dependable "base case". I get into an infinite loop, because 'make maintainer-clean', in order to "reset" the tree to a stable initial state can only work when the tree is already in a sufficiently stable state. I think this is a bug, and perhaps I ought to try and fix it. ;-) > > There's also a file called ..../src/Makefile.c. It isn't a valid C > > source file, but seems to be some sort of intermediate product, a > > ... way of using the C pre-processor, or something like that. > > Anybody got any idea WHO is generating this file, HOW, and more > > importantly, WHY???? Sometimes, when I do a make maintainer-clean, > > make first tries to build ..../src/Makefile by compiling > > ..../src/Makefile.c. > src/Makefile is built in an awkward way for hysterical raisins: it goes > from src/Makefile.in to Makefile.c (using m4) and then to Makefile > (using cpp). The second step is the original one, the first was added > when we started to introduce the use of autoconf. Hopefully at some > point someone comes around and will finish the transition so we can get > rid of the use of cpp there (which has been a source of bugs and > headaches). For some reason, that makes me feel better. :-) > >> AFAIK, normally removing lisp/loaddefs.el and lisp/eshell/esh-groups.el > >> and then rebuilding loaddefs.el should do the trick, and AFAIK "make > >> bootstrap" does that. > > I haven't got an esh-groups.el. I've somehow got an esh-groups.el~, > > though. And what generates esh-groups.el and how? Oh yes, if it's not > esh-groups is generated by running update-autoloads (i.e. as a side > effect of building loaddefs.el). esh-groups contains the autoloads of > some of the files in lisp/eshell (they do that by setting the > generated-autoload-file file-local variable). Thanks! I can see that now. > Stefan Have a good break! -- Alan Mackenzie (Nuremberg, Germany).