bug#40688: 28.0.50; Advice And ByteCompile Behavior Change

[Stefan Monnier]

> 4. As mentioned in this bug report at the outset I started seeing
> strange behavior (that also appeared non-deterministic across builds)
> where it felt like some of the advice was not defined (incidentally when
> the bug bit yesterday, C-h o still indicated the functions were
> adviced).

If it bites again, could you try and post (to the extent possible,
obviously) the function name, the output of (symbol-function
<thefunction>) along with as much as possible a concrete and detailed
description of an actual call's behavior on that function where we see
that the advice wasn't called?

> So wild conjecture:  Given make -j (the Makefile does impose some
> dependency order but not all)
> is it possible that things go south if something that is needed during
> the build of module-a.el gets byte-compiled *after* module-a.el?

In theory, no.  I (and many other people) build Emacs's `lisp` subdir in
parallel, and there are basically no dependencies in the makefile to try
and make sure files get compiled before they're used.  We've had some
corner case problems with it, but all the ones I know have been fixed.


        Stefan


> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>> IIUC after recompiling everything the problem disappeared.  If you
>> can't reproduce it any more, than I guess we can only close this
>> bug.
>>
>>> As an example, Module emacspeak-advice.el advices vc-next-action --- and
>>> this module (emacspeak-advice) is loaded early on during emacspeak
>>> initialization.
>>>
>>> When I later call vc-next-action during an emacs session and the
>>> autoload pulls in vc.el, the advice definition loaded earlier is not
>>> activated -- I have to explicitly reload module emacspeak-advice.
>>
>> In case you can still reproduce the problem, please show us what
>> `C-h o vc-next-action` tells you when you think it should have the
>> advice applied yet its behavior doesn't seem to be affected.
>>
>>
>>         Stefan
>>