Re: Failed pipeline for master | emacs | fd4992d3

Re: Failed pipeline for master | emacs | fd4992d3

[Jim Porter]

On 10/17/2022 7:01 PM, EMBA - Emacs Build Automation wrote:
> 
> 
> Pipeline #21175 has failed!
> 
> Project: emacs ( https://emba.gnu.org/emacs/emacs )
> Branch: master ( https://emba.gnu.org/emacs/emacs/-/commits/master )
> 
> Commit: fd4992d3 ( https://emba.gnu.org/emacs/emacs/-/commit/fd4992d356a9c4225cb518a6a5309aaa1d0f640b )
> Commit Message: Print the correct $PATH when Eshell's 'which' f...
> Commit Author: Jim Porter
> 
> Pipeline #21175 ( https://emba.gnu.org/emacs/emacs/-/pipelines/21175 ) triggered by EMBA bot ( https://emba.gnu.org/bot )
> had 1 failed build.
> 
> Job #56043 ( https://emba.gnu.org/emacs/emacs/-/jobs/56043/raw )
> 
> Stage: normal
> Name: test-lisp-eshell-inotify
> 

I don't quite understand why this is failing. The build logs say this:

-------------------------
In end of data:
eshell/esh-util.el:279:17: Warning: the function `setq-connection-local' 
is not known to be defined.
eshell/esh-util.el:272:4: Warning: the function 
`with-connection-local-application-variables' is not known to be defined.
-------------------------

But both of those macros have autoload cookies. Shouldn't that be all 
they need to work without explicitly requiring files-x? It works on my 
local builds...

Any ideas?

Re: Failed pipeline for master | emacs | fd4992d3

[Daniel Martín]

Jim Porter <jporterbugs@gmail.com> writes:
>
> I don't quite understand why this is failing. The build logs say this:
>
> -------------------------
> In end of data:
> eshell/esh-util.el:279:17: Warning: the function
> `setq-connection-local' is not known to be defined.
> eshell/esh-util.el:272:4: Warning: the function
> `with-connection-local-application-variables' is not known to be
> defined.
> -------------------------
>
> But both of those macros have autoload cookies. Shouldn't that be all
> they need to work without explicitly requiring files-x? It works on my
> local builds...

I also get the same warnings in a local build.  The autoload cookies
will load them at runtime, but you still need to make them available to
the compiler (otherwise, it cannot expand them).  The usual way to do
that is to simply (require 'files-x) with an eval-when-compile around
it, to prevent loading the file that contains the macros when someone
runs the code.

Re: Failed pipeline for master | emacs | fd4992d3

[Lars Ingebrigtsen]

Jim Porter <jporterbugs@gmail.com> writes:

> But both of those macros have autoload cookies. Shouldn't that be all
> they need to work without explicitly requiring files-x? It works on my
> local builds...
>
> Any ideas?

Our build logic wrt. autoload cookies, macros and loaddefs files is far
from perfect, so say the least.

I've now pushed a new ldefs-boot.el file, and after deleting
eshell/*.elc, the build now seems to work fine for me.

Re: Failed pipeline for master | emacs | fd4992d3

[Michael Albinus]

Jim Porter <jporterbugs@gmail.com> writes:

Hi Jim,

> I don't quite understand why this is failing. The build logs say this:
>
> -------------------------
> In end of data:
> eshell/esh-util.el:279:17: Warning: the function
> `setq-connection-local' is not known to be defined.
> eshell/esh-util.el:272:4: Warning: the function
> `with-connection-local-application-variables' is not known to be
> defined.
> -------------------------
>
> But both of those macros have autoload cookies. Shouldn't that be all
> they need to work without explicitly requiring files-x? It works on my
> local builds...
>
> Any ideas?

Such problems happen occasionally on emba, because there isn't a "make
bootstrap" every test run. The bootstrap happens with the scheduled runs
every 8 hours. If there was a successful bootstrap, and the problem
persist, we shall analyze further.

Best regards, Michael.

Re: Failed pipeline for master | emacs | fd4992d3

[Jim Porter]

On 10/18/2022 2:29 AM, Michael Albinus wrote:
> Such problems happen occasionally on emba, because there isn't a "make
> bootstrap" every test run. The bootstrap happens with the scheduled runs
> every 8 hours. If there was a successful bootstrap, and the problem
> persist, we shall analyze further.

Ah ha, I didn't realize that the per-commit EMBA builds were 
incremental. That explains it. I'll keep that in mind for the future.