eshell-defgroup fouls up `make bootstrap'.

eshell-defgroup fouls up `make bootstrap'.

[Alan Mackenzie]

Hi, Glenn,

I cvs updated yesterday and now can't build Emacs.  The problem is the
non-existence of eshell-defgroup.

eshell-defgroup is aliased to defgroup in .../lisp/eshell/eshell.el.
(As a matter of interest, why?)

I've tried putting an `(eval-and-compile ...)' round the definition of
eshell-defgroup, but this doesn't help.  It fails as follows:

    Loading loaddefs.el (source)...
    Symbol's function definition is void: eshell-defgroup

There's a comment in eshell.el just before the defalias about "putting
the whole definition into the autoload file" which I don't understand,
so I don't really want to mess around, here.

Would you look at this, please.  Thanks!

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Stefan Monnier]

> I cvs updated yesterday and now can't build Emacs.  The problem is the
> non-existence of eshell-defgroup.

> eshell-defgroup is aliased to defgroup in .../lisp/eshell/eshell.el.
> (As a matter of interest, why?)

> I've tried putting an `(eval-and-compile ...)' round the definition of
> eshell-defgroup, but this doesn't help.  It fails as follows:

>     Loading loaddefs.el (source)...
>     Symbol's function definition is void: eshell-defgroup

> There's a comment in eshell.el just before the defalias about "putting
> the whole definition into the autoload file" which I don't understand,
> so I don't really want to mess around, here.

> Would you look at this, please.  Thanks!

For what it's worth: "make bootstrap" *SHOULD* work.
It works for me here, so I don't know what's the problem at your end,
but if/when you figure it out, please send it back here so we can
address it.

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.


        Stefan

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

[Alan Mackenzie]

Hi,

On Wed, Jul 30, 2008 at 11:22:22AM -0400, Stefan Monnier wrote:
> > I cvs updated yesterday and now can't build Emacs.  The problem is the
> > non-existence of eshell-defgroup.

> > eshell-defgroup is aliased to defgroup in .../lisp/eshell/eshell.el.
> > (As a matter of interest, why?)

> > I've tried putting an `(eval-and-compile ...)' round the definition of
> > eshell-defgroup, but this doesn't help.  It fails as follows:

> >     Loading loaddefs.el (source)...
> >     Symbol's function definition is void: eshell-defgroup

> > There's a comment in eshell.el just before the defalias about "putting
> > the whole definition into the autoload file" which I don't understand,
> > so I don't really want to mess around, here.

> > Would you look at this, please.  Thanks!

> For what it's worth: "make bootstrap" *SHOULD* work.
> It works for me here, so I don't know what's the problem at your end,
> but if/when you figure it out, please send it back here so we can
> address it.

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?

However, the big problem is that Makefile regards itself as a target.  Do
make -nd maintainer-clean.  This should clear out the trash.  However,
this is what the start of the debugging output looks like:

GNU Make 3.80
Copyright (C) 2002  Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Reading makefiles...
Reading makefile `Makefile'...
Updating makefiles....
 Considering target file `Makefile'.
   Considering target file `config.status'.
     Considering target file `/home/acm/emacs/emacs/configure'.
		    
So "Makefile" is one of its own targets.  This is garbage - it's broken
worse than the wind.

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.

It's so broken, that I typically have to spend an entire one or two days
debugging the build process after doing a cvs update.  This is so painful
that it's making me want to just give up on Emacs altogether.  I've got
far better things to do with my time and energy than fighting this
garbage every time I do a cvs update.  The entire build system is rotten
to the core, so rotten that I feel insulted in being expected to use it,
in being expected to pretend that it's really more or less OK, with just,
perhaps, the odd little glitch to fix.  Somebody probably thought he was
being very clever in making Makefile one of its own targets, but sadly he
seems to have been too busy to get round to recording his wizardly
reasons in the comments.  He probably thought he was being super slick in
letting it get built by an explicit rule, too.  Our Makefiles should be
generated by ./configure, and then left severely alone.  Surely?

The totality of the Makefiles is ~4500 lines.  This is ludicrous.  It's
4.5k lines of ghastly spaghetti coding, filled up with useless, redundant
targets with fanciful flippant names.  Emacs is NOT that complicated to
build.  It's a touch more complex than a bog-standard C program perhaps,
but it's really just a straightforward sequence of 6 or 7 steps, starting
off with compiling the C files, and ending up dumping an executable.  200
lines, perhaps, plus a list of files?  We really don't need to expect
Makefiles to compile themselves out of syntactically-garbage
Makefile.c's, before we can clear back to a clean state.

And I haven't got anywhere near investigating why eshell-defgroup isn't
getting defined in time.

> 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
immediately obvious, because it's in an otherwise unused make variable
("AUTOGENEL") it's because I'm stupid, and there's no point explaining in
comments (in ..../lisp/Makefile) to somebody so dumb as me.

I'm sorry, I just can't care any more about Emacs, right at the moment.
Nothing personal.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Stefan Monnier]

> 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

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

[Alan Mackenzie]

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

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

[Stefan Monnier]

>> 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 is a base case, but since the Makefile is a generated file, the
base case doesn't use "make".  It uses ./configure instead.  So if you do

   ./configure
   make bootstrap

it may fix your problem (then again, I wouldn't be surprised if it
doesn't).  If you want to preserve some of your config, you can try

   ./config.status --recheck
   make bootstrap

instead, which is pretty close to the base case so it's likely to work
just as well (or just as poorly as the case may be).

>> src/Makefile is built in an awkward way for hysterical raisins: it goes
[...]
> For some reason, that makes me feel better.  :-)

How odd!


        Stefan