Re: PDUMP vs. UNION_TYPE + C++

JV> And possibly (at least at make install time), actually name the file JV> temacs.dpm.UNIQUEID so the user can have his personal dump files JV> around for multiple XEmacsen. I foresee a proliferation of temacs.dmp.826748274934 files. JV> - We want to keep the search logic in lisp[1], and thus the dump file JV> tied to the executable [ELF/COFF session] JV> - We want to make it possible for users/site to do their down dump JV> (for instance with the package autoloads preloaded, so XEmacs can JV> startup quickly). This would suggest NOT tying the dump file to JV> lisp. Yes. We should provide a command line flag to load the dump file, so that users can dump their own files with stuff. Ideally a user could just be running XEmacs with their own typical packages loaded, and create a dump file from the running session. We'd have to ignore buffers and window system objects, etc. (maybe hard). JV> This begs the question: Is it possible to restart the undump.., i.e. JV> - XEmacs starts up JV> - "loads" a tiny dump file from ELF section (presumably it possible to have JV> this already mapped by the loader). That way lies non-portability. C is a fine programming language. For XEmacs maintainers. JV> - This tiny dump file contains the startup lisp code that looks for JV> the XEmacs.dump.ID file JV> - Then the undumping starts again with the real XEmacs.dump.ID file