Re: Loading tramp for dump goes into infinite regress

[Lynn Winebarger]

On Sun, Jul 24, 2022 at 12:00 PM Lynn Winebarger <owinebar@gmail.com> wrote:
>
> On Sun, Jul 24, 2022 at 10:05 AM Lynn Winebarger <owinebar@gmail.com> wrote:
> >
> > On Sun, Jul 24, 2022 at 9:34 AM Eli Zaretskii <eliz@gnu.org> wrote:
> > >
> > > > From: Lynn Winebarger <owinebar@gmail.com>
> > > > Date: Sun, 24 Jul 2022 09:30:34 -0400
> > > > Cc: michael.albinus@gmx.de, emacs-devel@gnu.org
> > > >
> > > > > Note that Michael asked you to show specific commands you used, so he
> > > > > could try reproducing the problems you see, but you haven't provided
> > > > > any such commands, only a rather general description of what you are
> > > > > trying to do.
> > > > >
> > > > > Can you please show the shell commands that you use to do the loading
> > > > > step?
> > > >
> > > > That would be "make -j$(nproc)", which seems unhelpful.
> > >
> > > I mean the actual command that loads and dumps all the stuff.  If you
> > > are using the Emacs Makefile's, I guess it's something like this:
> > >
> > >   ./temacs -batch -l loadup --temacs=pdump
> > >
> > > Or did you modify the Makefile's in the tree?
> >
> > I have not modified the Makefiles at this point - hence the explicit
> > use of make-docfile in my previous reply.
> >
> > LC_ALL=C ./temacs -batch --no-build-details -l loadup --temacs=pdump
> > --bin-dest=/does/not/exist/bin
> > --eln-dest=/does/not/exist/lib/emacs/28.1
> >
> > This is probably obvious, but I am only running the resulting emacs
> > from the build directory.
>
> Additional note - if I delete the tramp-<hashes>.eln file from
> BUILD/native-lisp/28.1-<hash>/ without touching the corresponding elc
> file, the loading proceeds - although there are still issues to
> resolve in the subsequent tramp-X files being loaded.

Ok, after getting the load order of subsequent files corrected
(avoiding errors from an autoload or require during dumping), I got
the same behavior from loading "tramp-sh".  So I removed the eln (but
not elc) file for that library, and now the loading proceeds past the
tramp-X files.
That will work for my immediate purposes, but it seems like something
undesirable is going on between dumping and the native compilation
unit.
That being said, it would also be handy to break out the
tramp-loaddefs file into a "declarations" file that can be safely
required from tramp.el and an "initialization" file that can be loaded
at the end of tramp.el (or externally) to set up the tramp
initialization hooks. The current method of decoupling the
method-specific implementation files from the generic interface file
(by requiring tramp-loaddefs at a certain point in the tramp.el file)
does not seem compatible with including it in the dump.

Lynn