emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: eshell-defgroup fouls up `make bootstrap'.


From: Stefan Monnier
Subject: Re: eshell-defgroup fouls up `make bootstrap'.
Date: Thu, 31 Jul 2008 00:08:02 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux)

> 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]