* eshell-defgroup fouls up `make bootstrap'. @ 2008-07-30 9:48 Alan Mackenzie 2008-07-30 15:22 ` Stefan Monnier 0 siblings, 1 reply; 6+ messages in thread From: Alan Mackenzie @ 2008-07-30 9:48 UTC (permalink / raw) To: Glenn Morris; +Cc: emacs-devel 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). ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: eshell-defgroup fouls up `make bootstrap'. 2008-07-30 9:48 eshell-defgroup fouls up `make bootstrap' Alan Mackenzie @ 2008-07-30 15:22 ` Stefan Monnier 2008-07-30 22:07 ` Alan Mackenzie 0 siblings, 1 reply; 6+ messages in thread From: Stefan Monnier @ 2008-07-30 15:22 UTC (permalink / raw) To: Alan Mackenzie; +Cc: Glenn Morris, emacs-devel > 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: eshell-defgroup fouls up `make bootstrap'. 2008-07-30 15:22 ` Stefan Monnier @ 2008-07-30 22:07 ` Alan Mackenzie 2008-07-31 4:08 ` Stefan Monnier 0 siblings, 1 reply; 6+ messages in thread From: Alan Mackenzie @ 2008-07-30 22:07 UTC (permalink / raw) To: Stefan Monnier; +Cc: Glenn Morris, emacs-devel 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). ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: eshell-defgroup fouls up `make bootstrap'. 2008-07-30 22:07 ` Alan Mackenzie @ 2008-07-31 4:08 ` Stefan Monnier 2008-07-31 17:10 ` Alan Mackenzie 0 siblings, 1 reply; 6+ messages in thread From: Stefan Monnier @ 2008-07-31 4:08 UTC (permalink / raw) To: Alan Mackenzie; +Cc: Glenn Morris, emacs-devel > 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: eshell-defgroup fouls up `make bootstrap'. 2008-07-31 4:08 ` Stefan Monnier @ 2008-07-31 17:10 ` Alan Mackenzie 2008-07-31 20:32 ` Stefan Monnier 0 siblings, 1 reply; 6+ messages in thread From: Alan Mackenzie @ 2008-07-31 17:10 UTC (permalink / raw) To: Stefan Monnier; +Cc: Glenn Morris, emacs-devel 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). ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: eshell-defgroup fouls up `make bootstrap'. 2008-07-31 17:10 ` Alan Mackenzie @ 2008-07-31 20:32 ` Stefan Monnier 0 siblings, 0 replies; 6+ messages in thread From: Stefan Monnier @ 2008-07-31 20:32 UTC (permalink / raw) To: Alan Mackenzie; +Cc: Glenn Morris, emacs-devel >> 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2008-07-31 20:32 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2008-07-30 9:48 eshell-defgroup fouls up `make bootstrap' Alan Mackenzie 2008-07-30 15:22 ` Stefan Monnier 2008-07-30 22:07 ` Alan Mackenzie 2008-07-31 4:08 ` Stefan Monnier 2008-07-31 17:10 ` Alan Mackenzie 2008-07-31 20:32 ` Stefan Monnier
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).