Re: Noisy byte compilation on master

[Stefan Monnier]

> The next problem are those "Obsolete name arg 'foo' to constructor"
> messages.  I cannot simply omit the names as this won't work with older
> EIEIO.

Indeed, you'd have to use `make-instance'.
Or you could use a macro which either drops the name argument or passes
it depending on the version of EIEIO with which it's compiled.

>   (require 'ede/proj-elisp)
>   (child-of-class-p 'ede-proj-target-elisp 'ede-target)
> used to work fine, but now `child-of-class-p' has those cl-check-types
> in it.  Is that on purpose?

Looks like a bug.  It's been changed to accept class arguments (rather
than class names), but it should also accept class names, as before.

>>> Also, if I understand you correctly, this would mean that
>>> core packages cannot depend on CEDET.
>> Indeed, that'd be the downside.
> A pretty major one, I would say.

Agreed.

> That's not what I mean.

I don't understand, then.

> For instance, there's the requirement that changes have to
> appear under the date they entered Emacs trunk,

Obviously, you won't be affected by this requirement any more once Emacs
starts generating the ChangeLogs mechanically.

> and that you should not have several entries from the same author for
> the same day.

Not sure where you ot that idea, but we don't have such a requirement.
I even often setup such multiple-entries-from-the-guy-same-day *by
hand*, when I feel like it helps structure the ChangeLog.

> Then there's the problem that the Changelog will also contain changes
> from files that are only upstream, which you'll have to delete.

How would that affect you, since "we" (i.e. Paul) write the scripts that
(will) generate the ChangeLogs (IIUC we'll generate a single ChangeLog
for the whole Emacs tree)?

> And on top of that, CEDET's files are scattered across the Emacs
> codebase, affecting many different Changelogs: not only that for
> 'lisp/cedet', but also 'lisp/emacs-lisp', 'admin', 'etc', 'doc', and
> there's even one for 'test'!

But once we start generating the ChangeLogs mechanically you won't need
to care any more (maybe we'll need to care if we want to generate
equivalent ChangeLogs, but so far the intention has been to do
something simpler).

> All of this is a *huge* pain,

I understand it's annoying, but I don't understand why you think that us
moving to auto-generated ChangeLogs won't solve those problems for you.


        Stefan