From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: eshell-defgroup fouls up `make bootstrap'. Date: Thu, 31 Jul 2008 00:08:02 -0400 Message-ID: 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 1217477311 15070 80.91.229.12 (31 Jul 2008 04:08:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 31 Jul 2008 04:08:31 +0000 (UTC) Cc: Glenn Morris , emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jul 31 06:09:21 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 1KOPTa-00079E-Kr for ged-emacs-devel@m.gmane.org; Thu, 31 Jul 2008 06:09:18 +0200 Original-Received: from localhost ([127.0.0.1]:35930 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KOPSg-0007ee-05 for ged-emacs-devel@m.gmane.org; Thu, 31 Jul 2008 00:08:22 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KOPSa-0007bk-Qi for emacs-devel@gnu.org; Thu, 31 Jul 2008 00:08:16 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KOPSZ-0007a4-Lm for emacs-devel@gnu.org; Thu, 31 Jul 2008 00:08:16 -0400 Original-Received: from [199.232.76.173] (port=57216 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KOPSZ-0007Zv-Hs for emacs-devel@gnu.org; Thu, 31 Jul 2008 00:08:15 -0400 Original-Received: from ironport2-out.pppoe.ca ([206.248.154.182]:49318 helo=ironport2-out.teksavvy.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KOPSS-0007kU-31; Thu, 31 Jul 2008 00:08:08 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArEEAAjXkEhFxIYw/2dsb2JhbACBW4lDpWKBdQ X-IronPort-AV: E=Sophos;i="4.31,283,1215403200"; d="scan'208";a="24993023" Original-Received: from 69-196-134-48.dsl.teksavvy.com (HELO pastel.home) ([69.196.134.48]) by ironport2-out.teksavvy.com with ESMTP; 31 Jul 2008 00:08:03 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 49AE27F33; Thu, 31 Jul 2008 00:08:02 -0400 (EDT) In-Reply-To: <20080730220721.GA1920@muc.de> (Alan Mackenzie's message of "Wed, 30 Jul 2008 22:07:21 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-detected-kernel: by monty-python.gnu.org: Genre and OS details not recognized. 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:101782 Archived-At: > 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 > So "Makefile" is one of its own targets. This is garbage - it's broken > worse than the wind. 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. > 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 > clever-dick 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. > This is so broken that it's beyond even being a joke. 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). >> 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). Stefan