unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Lute Kamstra <Lute.Kamstra.lists@xs4all.nl>
Cc: emacs-devel@gnu.org
Subject: Re: generic-x needs to require generic
Date: Tue, 22 Mar 2005 16:36:33 +0100	[thread overview]
Message-ID: <87br9b7kvy.fsf@xs4all.nl> (raw)
In-Reply-To: <87zmwwgke5.fsf@xs4all.nl> (Lute Kamstra's message of "Tue, 22 Mar 2005 09:22:26 +0100")

Lute Kamstra <Lute.Kamstra.lists@xs4all.nl> writes:

> Luc Teirlinck <teirllm@dms.auburn.edu> writes:
>
>> What is the purpose of the following change to generic-x, which breaks
>> bootstrapping:
>>
>> 	* generic-x.el: Don't prevent compilation.  Don't require generic.
>> 	Follow coding conventions.  Minor code cleanup.
>>
>> I am referring to the "Don't require generic." part.  Undoing that
>> part solves the following problem during bootstrapping:
>
> The function generic-make-keywords-list that is called in generic-x is
> defined in generic. So it should probably be autoloaded.
> Alternatively generic-x could (eval-when-compile (require 'generic))
> and (eval-when-compile ...) all calls to generic-make-keywords-list as
> well.
>
> I missed this because bootstrapping my working-tree worked just fine.
> I also did an update for another tree without the generic{,-x}.el
> patches and it bootstrapped fine.  A clean checkout fails to
> bootstraps however.
>
> This is quite strange.  I guess that for me the define-generic-mode
> calls in generic-x that precede the generic-make-keywords-list call
> autoload generic so that generic is loaded when the call to
> generic-make-keywords-list is compiled.  Why this doesn't happen for
> you of for a clean checkout beats me.
>
> I'll put (require 'generic) back in for now to enable bootstrapping.

I've investigated this some more and I'm a bit puzzled.  Maybe someone
can help me.

When I remove the (require 'generic) from lisp/generic-x.el and do a
"make maintainer-clean", "./configure", and "make bootstrap", I see:

,----
| [...]
| 
| Generating autoloads for generic.el...
| Generating autoloads for generic.el...done
| 
| [...]
| 
| Compiling /soft/tmp/emacs/lisp/./generic-x.el
| 
| In toplevel form:
| generic-x.el:160:22:Warning: reference to free variable
|     `apache-conf-generic-mode'
| generic-x.el:177:22:Warning: reference to free variable
|     `apache-log-generic-mode'
| generic-x.el:191:22:Warning: reference to free variable `samba-generic-mode'
| generic-x.el:207:22:Warning: reference to free variable `fvwm-generic-mode'
| generic-x.el:233:22:Warning: reference to free variable
|     `x-resource-generic-mode'
| generic-x.el:244:22:Warning: reference to free variable `hosts-generic-mode'
| generic-x.el:255:22:Warning: reference to free variable `inf-generic-mode'
| generic-x.el:267:22:Warning: reference to free variable `ini-generic-mode'
| generic-x.el:287:22:Warning: reference to free variable `reg-generic-mode'
| generic-x.el:303:22:Warning: reference to free variable `bat-generic-mode'
| generic-x.el:444:22:Warning: reference to free variable
|     `mailagent-rules-generic-mode'
| generic-x.el:461:22:Warning: reference to free variable
|     `prototype-generic-mode'
| generic-x.el:484:22:Warning: reference to free variable `pkginfo-generic-mode'
| generic-x.el:496:22:Warning: reference to free variable
|     `javascript-generic-mode'
| generic-x.el:574:22:Warning: reference to free variable `vrml-generic-mode'
| generic-x.el:628:22:Warning: reference to free variable
|     `java-manifest-generic-mode'
| generic-x.el:648:22:Warning: reference to free variable
|     `java-properties-generic-mode'
| generic-x.el:679:22:Warning: reference to free variable `alias-generic-mode'
| generic-x.el:767:8:Error: Symbol's function definition is void: generic-make-keywords-list
| make[1]: *** [compile] Error 1
| make[1]: Leaving directory `/soft/tmp/emacs/lisp'
| make: *** [bootstrap-build] Error 2
`----

The warnings indicate that the define-generic-mode macro is not
defined when generic-x.el is compiled.  define-generic-mode is an
autoloaded macro in generic.el and it seems that autoloads for
generic.el are created.  So why isn't generic loaded when generic.el
is compiled?

What I find puzzling as well is that when I do a second "make
bootstrap" after the first failed, things just work fine:

,----
| [...]
| 
| Compiling /soft/tmp/emacs/lisp/./generic-x.el
| 
| In end of data:
| generic-x.el:1821:1:Warning: the following functions are not known to be
|     defined: w32-shell-name, comint-mode, comint-exec
| Wrote /soft/tmp/emacs/lisp/generic-x.elc
| 
| [...]
`----


Lute.

  reply	other threads:[~2005-03-22 15:36 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-21 21:07 generic-x needs to require generic Luc Teirlinck
2005-03-22  8:22 ` Lute Kamstra
2005-03-22 15:36   ` Lute Kamstra [this message]
2005-03-22 16:44     ` Andreas Schwab
2005-03-22 17:23       ` Lute Kamstra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87br9b7kvy.fsf@xs4all.nl \
    --to=lute.kamstra.lists@xs4all.nl \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).