bug#40688: 28.0.50; Advice And ByteCompile Behavior Change

[Stefan Monnier]

> .el files are not generated by Makefile rules.
>
> Again, conjecture: perhaps I'm hitting this because:
>
> 1. Emacspeak uses advice far more than emacs does?

Could be.  Might be linked to the use `defadvice` (which has
a funny/broken behavior w.r.t macro expansion), but I can't think of
a good scenario where that would play a role.

Digging into the `symbol-function` value (and/or Edebugging) is the only
way I can imagine we will be able to track it down.


        Stefan


>  >> I didn't mean the -j bit in building emacs, conjecture is that emacspeak
>>> breaks if -j is used.
>>
>> I was pointing out that Emacs's own use of `-j` to build the `lisp`
>> subdir indicates that it's OK to have missing dependencies on the `.elc`
>> files (and hence sometimes the .el file is loaded and sometimes the
>> `.elc`, depending on the compilation order; or even the `.el` file is
>> loaded while the corresponding `.elc` file is being generated).
>>
>> Of course, if your `.el` files are generated by makefile rules that's
>> a completely different question.
>>
>>
>>         Stefan
>>
>>
>>>>> 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
>>>>>>
>>>>
>>