[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Dependency graph for Emacs Lisp files

From: Lars Ingebrigtsen
Subject: Re: Dependency graph for Emacs Lisp files
Date: Thu, 01 Aug 2019 15:26:23 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

Stefan Monnier <address@hidden> writes:

> The result was rather disappointing:
> 1- lots of cycles
> 2- incomplete dependencies (mostly due to autoloads).
> 3- too many dependencies, resulting in excessive recompilation for
>    my taste

Very excessive recompilation wouldn't be nice...

> I believe (1) has improved over the years, but I'm sure there's still
> a fair bit of that.  Make didn't like them back then, and I don't think
> it likes them more now.  So we'd need some way to fix that (I guess we
> could add some annotations in the source code to "ignore" some
> dependencies).

But are cycles a problem?  You just delete all the .elc files in the
cycle and then stop.

> For (2), I think a better option is to generate the dependencies as
> a side-effect of compilation using after-load-functions: we should be
> able to collect reliably all the dependencies this way, regardless of
> how the files get loaded.

Hm...  interesting.  That makes me wonder whether the same thing could
be used to collect the requires, too?

> Regarding (3), I'm not sure how to deal with that.  The problem is all
> the (require 'foo) which are only really needed at run time.  There are
> various ways we could try and tackle the problem, but they all seem to
> be way too invasive.

Speaking of excessive recompilation, it seems like all the .c files are
recompiled just about whenever anybody does something trivial in a .h
file, but I guess that's unavoidable.  (I get the feeling that every day
when I do a "git pull" I get a full recompilation of the C bits in
Emacs, and then a couple of .el files, but perhaps that's not completely

(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

reply via email to

[Prev in Thread] Current Thread [Next in Thread]