bug#40688: 28.0.50; Advice And ByteCompile Behavior Change

[T.V Raman]

Hi Stefan,

I have a conjecture as to when/how this bug bites, wanted to run the
thought by you.

So the bug bit again yesterday --- and here is how it went away:

1. Emacspeak is made up of a large number of modules  and many of the
"extension" modules that define package-specific advice load earlier
core modules.

2. I've always done a require of these dependencies and the byte-compile
is clean, ie almost 0 warnings from the emacspeak side.

3. I have a Makefile to do the build, and about a year ago (or may be
two) I  added "-j" to  one of the Makefile targets.

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).

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? 
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
>

--