[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: eshell-defgroup fouls up `make bootstrap'.
From: |
Alan Mackenzie |
Subject: |
Re: eshell-defgroup fouls up `make bootstrap'. |
Date: |
Thu, 31 Jul 2008 17:10:13 +0000 |
User-agent: |
Mutt/1.5.9i |
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).