[issue] CEDET shadowed library bugs (was: auto-autoloads errors)

Mike Kupfer writes: If we're still talking about the "auto-autoloads already loaded" error-morphed-to-warning, this isn't going to help figure it out. The shadow-finding code has to ignore auto-autoloads, because there's one in *every* package by design. Same for custom-load, except that not all packages have one of those (most do). That said, the output is "interesting" (thus the [issue] tag). Use M-x list-load-path-shadows for nicer output. This is a bug. (Verified in my straight-from-hg package source tree.) I don't know whose offhand. Since libraries are uniquely identified to `load' by their file names, it is an error to have two libraries in sibling packages with the same name. sformat.el has a 0-line diff, but working.el has a 151-line diff! So this is actually broken (since 2003?): 2003-09-24 David Ponce <david(a)dponce.com&gt; * sformat.el, working.el: Move to common. * Makefile: Re-generate. * Project.ede (tools): Remove sformat.el and working.el from target sources. This too. Ben did this, arguing that menu-building is a core function. I see his point. It can't be added to 21.1 or 21.4 in the same way, thus the duplication. But it's not a problem, it should be handled by `package-suppress' (don't ask until you've donned acid-resistent clothing -- highly corrosive!) IMO, this is a bug in shadow.el, which should probably participate in the package-suppress protocol (I would say by warning about it). Not a core function, but this was done (by Adrian?) so that users don't have to have packages available to submit a build report. Makes sense. Ditto on the package-suppress, I think. I think Aidan or Mats did this. APEL's deprecated but these functions are very useful. Ditto package-suppress. Ben, again. Ditto package-suppress. Steve _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta