all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Ken Raeburn <raeburn@raeburn.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: Emacs development discussions <emacs-devel@gnu.org>
Subject: Re: build broken: no defun org-float-time.  Who's guilty, and what does he propose?
Date: Mon, 7 Sep 2009 19:39:32 -0400	[thread overview]
Message-ID: <88A44246-FB18-46DB-B92D-00E1716F5F68@raeburn.org> (raw)
In-Reply-To: <83tyze34fd.fsf@gnu.org>

On Sep 7, 2009, at 16:06, Eli Zaretskii wrote:
> We have `features' and `load-history' to help us.

Yes.

> Files loaded by loadup.el are easily extracted by simple text
> scanning, and the byte compiler itself indeed _is_ a prerequisite for
> every other compilation.

But if a minor comment change is made in the compiler source, must we  
recompile everything?  We don't generally make .o files explicitly  
depend on the C compiler.  Though, in the gcc project they probably  
do... so, yeah, maybe it's the way to go.

> Btw, I don't understand what problem do you see with files preloaded
> by loadup.  They should simply be all prerequisites of temacs, and
> that's it, right?


Well, "emacs", not "temacs" which is just linked from the C code, but  
also I was assuming we wouldn't make the emacs binary an explicit  
dependency for the .elc files; otherwise, someone downloading and  
building a release will have to recompile all the elisp code even  
though the results will differ from everyone else's only in the first  
few comment lines.

And I'm not sure if we want to list all those files as dependencies  
anyways.  We might indeed want to recompile everything if subr.el  
changes, if we can't figure out what actually used stuff from that  
file.  On the other hand, we probably don't want to recompile  
everything because lisp/language/georgian.el changed.  (Conservatively  
speaking, I suppose we should, in case someone decided to redefine  
'defcustom' there.)  Actually, I think we want to rebuild if subr.elc  
changes, other than the comments indicating who compiled it and when,  
not just for all subr.el changes, and likewise for the compiler code....

Ken




  reply	other threads:[~2009-09-07 23:39 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-07  9:28 build broken: no defun org-float-time. Who's guilty, and what does he propose? Alan Mackenzie
2009-09-07  9:47 ` Andreas Schwab
2009-09-07  9:52 ` joakim
2009-09-07 10:09   ` Lennart Borgman
2009-09-07 11:37     ` joakim
2009-09-07 10:30   ` Jan D.
2009-09-07 17:42     ` Eli Zaretskii
2009-09-07 17:59       ` Ken Raeburn
2009-09-07 18:32         ` Drew Adams
2009-09-07 18:42           ` Lennart Borgman
2009-09-07 19:22             ` Ken Raeburn
2009-09-07 19:03         ` Glenn Morris
2009-09-07 19:20           ` Drew Adams
2009-09-07 20:08           ` Eli Zaretskii
2009-09-07 21:43             ` more reliable `make' Glenn Morris
2009-09-08 16:46               ` Stefan Monnier
2009-09-10  6:28                 ` Glenn Morris
2009-09-10 13:37                   ` Stefan Monnier
2009-09-07 20:59           ` build broken: no defun org-float-time. Who's guilty, and what does he propose? joakim
2009-09-07 21:39             ` Glenn Morris
2009-09-07 21:55               ` joakim
2009-09-07 21:13           ` Alan Mackenzie
2009-09-08 16:48             ` Stefan Monnier
2009-09-08 18:17               ` build broken: no defun org-float-time. A workaround Alan Mackenzie
2009-09-08 19:08                 ` Ken Raeburn
2009-09-07 20:06         ` build broken: no defun org-float-time. Who's guilty, and what does he propose? Eli Zaretskii
2009-09-07 23:39           ` Ken Raeburn [this message]
2009-09-08  2:41             ` Stephen J. Turnbull
2009-09-08  3:20             ` Eli Zaretskii
2009-09-08  7:54               ` Ken Raeburn
2009-09-08 17:47                 ` Eli Zaretskii
2009-09-08 18:32                   ` Ken Raeburn
2009-09-08 17:01           ` Stefan Monnier
2009-09-08 17:51             ` Eli Zaretskii
2009-09-09  3:14               ` Stefan Monnier
2009-09-08  2:37       ` Stephen J. Turnbull
2009-09-08  3:14         ` Eli Zaretskii
2009-09-08 17:11   ` Stefan Monnier
2009-09-07 10:05 ` Miles Bader
2009-09-07 11:15   ` joakim
2009-09-07 13:35   ` Alan Mackenzie

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

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

  git send-email \
    --in-reply-to=88A44246-FB18-46DB-B92D-00E1716F5F68@raeburn.org \
    --to=raeburn@raeburn.org \
    --cc=eliz@gnu.org \
    --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 external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.