bug#40688: 28.0.50; Advice And ByteCompile Behavior Change

[T.V Raman]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

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

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

--