Re: Loading tramp for dump goes into infinite regress

[Lynn Winebarger <owinebar@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2785 bytes --]

On Sun, Jul 24, 2022, 3:55 AM Michael Albinus <michael.albinus@gmx.de>
wrote:

> Lynn Winebarger <owinebar@gmail.com> writes:
>
> Hi Lynn,
>
> > And I don't even know where to start describing the issue.
>
> I don't even understand what you're trying. Could you pls give the
> commands you're calling, that I have a chance to reproduce?
>

Good point.  I'm trying to dump a "fully-loaded" emacs 28.1 that includes
several hundred packages from the various elpas.  I've modified those
packages so they reside in site-lisp, use cl-lib instead of cl, and use an
explicit data directory instead of loading files relative to the location
of an installed .el file.
I verified these all "work" by having about 1000 require statements in my
.emacs file to explicitly require them.  I then took the load history and
separated the files into ones from the lisp directory and ones from
site-lisp.  I created a site-load.el and site-lisp-load.el (loaded at the
end of site-load.el) to explicitly load the files in something resembling
dependency order, then running make in the emacs build directory to create
the build.
I've also compiled every ELISP source file using
batch-byte+native-compile.  That was really painful since, as far as I
know, the files can't be native compiled in parallel in arbitrary order
because of potential race conditions, and I haven't made a Makefile for the
.ELN files with the correct dependencies to native compile them in
dependency order using make to build them in parallel.

Now I'm working through the site-load.el file to dump all the required core
emacs ELISP files first (in addition to the ones in loadup) to get the
ordering right.  Tramp is somewhere in the 300s in the list, maybe
halfway-through the list of core emacs files.

I don't really expect anyone to be able to solve this for me.  I'm just
looking for some pointers on how I can figure out what is going on short of
stepping through the dumping process with gdb.

At this point, I'm just trying to figure out why I can native compile
tramp, but the load statement during the load preparing for dumping goes
into infinite regress.  The "require 'tramp-loaddefs" statement was an
obvious problem, so I took the steps I described in my first email to
resolve them.  I just don't understand what's going on when I end the
tramp.el file with "(eval-and-compile (provide 'tramp))" and comment out
the final statements that run the initialization hook.  When I try to
native compile that version of tramp.el, it still seems to attempt to run
the initialization hook when the provide statement is evaluated during the
compile.  I have no idea why that is happening.  I would suspect something
along the lines of "with-eval-on-load 'tramp", but I can't find it.

Any ideas would be appreciated.

Lynn

[-- Attachment #2: Type: text/html, Size: 3877 bytes --]