Re: Source file '.../killer-source.el' newer than byte-compiled file

[Emanuel Berg <moasenwood@zoho.eu>]

Nick Dokos wrote:

>>> You can concoct Make rules for that
>>
>> ... how? You mean manually? If so, I'm
>> afraid that's totally out of the question,
>> as I have 64 `provide's and 284 `require's!
>>
>
> This is called "topological sorting" and you
> can use the tsort(1) program to do that,
> although you will have to prepare an input
> file that describes the dependencies in the
> format that tsort expects:
>
> (info "(coreutils) tsort invocation")

Cool stuff, straight CS, but if it has to be
done manually, it's out of the question, as
I `require' stuff back and forth all the time!
To have a file to describe that would be so
much extra work, and not only that, but the
worst part, boring and error-prone extra work.
Unless you have a tool to analyze my Elisp,
grep the requires, parse the catch, and direct
it to a file in the format that's needed...

Besides, mustn't I then even hook it to make(1)
as well, or is there yet another tool for that?

So no, I don't think I'll do that, but it is
still interesting, so if you have an example
I'd like to see it, of course :)

OK, hands down, this error doesn't come that
often. When it does, if one could only know
_what files_ require an old .elc, one could
simply touch(1) those one or two files
and recompile!

So again, if the byte-compiler knows this (the
name of the file), it would help if it
outputted them! With errors and warnings, this
always happens. Why not now as well?

However, I think I can modify the Makefile so
that, whenever there is this warning, output
the name of the file that is being compiled!

The simplest solution, right?

But I'd still like to know what it means in
theory as well as possible practice when
a requires an old b, and c requires a new b,
and a, b and c are part of the same
Emacs system?

-- 
underground experts united
http://user.it.uu.se/~embe8573