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

[Alan Mackenzie <acm@muc.de>]

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).