January 2001 - XEmacs-Beta - XEmacs Mailing List Archives

Re: Building with pdump litters /usr/local/bin 23 years, 10 months

Michael Sperber

>>>>> "Nick" == Nick V Pakoulin <npak(a)ispras.ru> writes: Nick> intro: "NVP" == Nick V Pakoulin <npak(a)ispras.ru> writes: Nick> Ok, i thought a little bit, looked at the Makefile and some understanding seems Nick> to come to my mind ... Nick> Building with pdump results in two files -- executable (temacs) and Nick> corresponding dumped lisp. Right? Nick> Then why not to keep dumped part somewhere under ${datadir}/${instvardir}/ ? Because the code for *finding* ${datadir}/${instvardir}/ lives in the image. And no, it's not easy or advisable to pull it back into temacs. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

Re: Building with pdump litters /usr/local/bin 23 years, 10 months

Nickolay Pakoulin

intro: "NVP" == Nick V Pakoulin <npak(a)ispras.ru> writes: Ok, i thought a little bit, looked at the Makefile and some understanding seems to come to my mind ... Building with pdump results in two files -- executable (temacs) and corresponding dumped lisp. Right? Then why not to keep dumped part somewhere under ${datadir}/${instvardir}/ ? On my system xemacs-21.2-b41-3a68d0b7.dmp is the only non-executable out of 186 files in /usr/local/bin and I strongly objects to filling bin/ with any kind of data files whether they come with XEmacs or something else. bin/ for executables, and share/ include/ lib/ etc-etc-etc for all else. Hope you see my point: I'm not against pdump, I'm for keeping dumped part in an appropriate data dir. Nick. NVP> Today I build xemacs with pdumper for the first time. What impressed me NVP> greatly is relatively small size of executable: xemacs-21.2-b38 : NVP> 10353561 xemacs-21.2-b40 : 10360804 src/xemacs(w/o pdump) : 10363983 NVP> xemacs-21.2-b41 : 7278787 !!! NVP> All of them are configured with mule, error-checking and debug info NVP> enabled, but the latter is dumped by pdumper. NVP> What seems strange, is the origin of the following file: -rw-r--r-- NVP> 2643988 Jan 17 15:21 /usr/local/bin/xemacs-21.2-b41-3a68d0b7.dmp NVP> My system: Linux-2.4.0 i686 glibc-2.1.1 NVP> Nick.

2 participants
1 comments

Re: INSTALL file for xemacs-packages CVS 23 years, 10 months

Stephen J. Turnbull

Moved from xemacs-review to xemacs-beta. I think the context is sufficient. >>>>> "mb" == Martin Buchholz <martin(a)xemacs.org> writes: mb> Does `make install' actually work now? (See old bug report of mb> mine) Yes. I've just done `make World' three times (and will do it again since I just updated to "Important byte-compiler patch" a few minutes ago). This is with (gradually improving versions of) my patch, but I think it may work with just Jan's. I think `make World' now actually works on a buck-naked system with nothing resembling an Emacs on it yet. (Ie, `cvs checkout xemacs xemacs-packages; cd xemacs; configure; make; cd ../xemacs-packages; ../xemacs/src/xemacs Local.rules; make World should work). I haven't tested it. I _have_ checked that there is _nothing_ but the dumped Lisp (in the binary) and the core Lisp on load-path, except for what package-compile.el explicitly puts there, when xemacs is used to build packages. So it should work in theory. mb> What I personally want is to be able to build my own sumos mb> (directories, not tarballs) SUMO specifically refers to the tarballs. make install does what you want for me (modulo I don't use SYMLINK = t). mb> built with my choice of weird byte-compiler. I'd like to run mb> in-place, so I would want the symlink method. In-place is only a space saver (admittedly, we're talking about nearly 90MB now if you don't clean the source tree). This is not at all the same as "in-place" for xemacs itself. I don't think this is a good idea if you're actually gonna have mango and banana as well as vanilla byte-compilers around, though. Install them and use EMACSPACKAGEPATH. mb> So whatever the build method, I should only have to specify 4 mb> variables, then run make install. That doesn't seem to be mb> possible now. I don't want to fiddle with explicit lists of mb> packages, since if the sumo list is changed, I want the new mb> packages added to my personal sumo. I think you can get this by adding two new variables to XEmacs.rules or maybe Local.rules.mk (or maybe a new include file specifically to hold them) ALL_XEMACS_PACKAGES and ALL_MULE_PACKAGES. Then these will be updated by CVS, and you can set XEMACS_PACKAGES = $(ALL_XEMACS_PACKAGES) MULE_PACKAGES = $(ALL_MULE_PACKAGES) Nomenclature could use some thought here, though. The process has changed a lot since Steve Baur designed it, and I think a number of variables could probably be coalesced with judicious nested references. Certainly a lot of names lack intuitiveness now. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."

1 participants
0 comments

Re: Solaris and gcc 2.95.2? 23 years, 10 months

Raymond Toy

>>>>> "Robert" == Robert Pluim <rpluim(a)bigfoot.com> writes: Robert> +normally held in /usr/ccs/bin. This can be done by adding Robert> +-B/usr/ccs/bin to CFLAGS used to configure XEmacs, or by uninstalling That should be -B/usr/ccs/bin/. The trailing "/" is required because gcc just appends the name to the option so it will try to find /usr/ccs/binld, which probably doesn't exist. Ray

3 participants
4 comments

Re: Core Dump on make install latest 21.2 from CVS 23 years, 10 months

Michael Sperber

>>>>> "Stephen" == Stephen J Turnbull <turnbull(a)sk.tsukuba.ac.jp> writes: Stephen> Per Gunnar's recent post: this kind of discussion be on XEmacs Beta. Stephen> I think this is enough context. >>>>> "ms" == Michael Sperber <sperber(a)informatik.uni-tuebingen.de> writes: ms> Now, some files in dumped-lisp.el already have the mule/ ms> prefix explicit like so: ms> (when-feature mule "mule/cyrillic") ; overloaded in leim/quail ms> Any objection against doing the same for the rest of them and ms> reverting the change? Stephen> Not from me; as a mule kind of person I would _prefer_ that stuff be Stephen> explicitly labelled that way. OK, sure. Another question for the Mule folks: dumped-lisp.el loads *every single file* in lisp/mule. This means I could skip loading custom-load and auto-autoloads in that directory. I want to. Any objections? -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla

3 participants
2 comments

Re: Core Dump on make install latest 21.2 from CVS 23 years, 10 months

Michael Sperber

>>>>> "Stephen" == Stephen J Turnbull <turnbull(a)sk.tsukuba.ac.jp> writes: Stephen> Per Gunnar's recent post: this kind of discussion be on XEmacs Beta. Stephen> I think this is enough context. >>>>> "ms" == Michael Sperber <sperber(a)informatik.uni-tuebingen.de> writes: Martin> Try removing all the .elc files (perhaps in a mule Martin> xemacs), then running make: Stephen> [...] Martin> "Error: Library file mule-charset not found" Martin> (Shouldn't make abort if there's a Lisp error during Martin> update-elc?) Stephen> I think so. ms> So OK, the mule files live in lisp/mule, I never realized ms> that. Sorry about that ... ms> I've bumped the recursion depth, but this adds something like ms> 331 stats to the startup time (according to Hrvoje). Stephen> Ugh. ms> Now, some files in dumped-lisp.el already have the mule/ ms> prefix explicit like so: ms> (when-feature mule "mule/cyrillic") ; overloaded in leim/quail ms> Any objection against doing the same for the rest of them and ms> reverting the change? Stephen> Not from me; as a mule kind of person I would _prefer_ that stuff be Stephen> explicitly labelled that way. Stephen> How about "term/*"? Could that have the same problems? No, already done there. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

2 participants
1 comments

Re: Core Dump on make install latest 21.2 from CVS 23 years, 10 months

Michael Sperber

[moved to xemacs-beta] >>>>> "Martin" == Martin Buchholz <martin(a)xemacs.org> writes: >>>>> "MS" == Michael Sperber <sperber(a)informatik.uni-tuebingen.de> writes: >>>>> "Martin" == Martin Buchholz <martin(a)xemacs.org> writes: MS> So OK, the mule files live in lisp/mule, I never realized that. Sorry MS> about that ... MS> I've bumped the recursion depth, but this adds something like 331 MS> stats to the startup time (according to Hrvoje). MS> Now, some files in dumped-lisp.el already have the mule/ prefix MS> explicit like so: MS> (when-feature mule "mule/cyrillic") ; overloaded in leim/quail MS> Any objection against doing the same for the rest of them and MS> reverting the change? Martin> Yes. I object. Martin> It's tradtional that all directories containing .el files are on Martin> the load-path. For example, it's natural to do (interactively) Martin> M-x load-library RET FOO RET Martin> and expect FOO.elc to be loaded. Martin> Although having a nested structure like you propose is Martin> basically a good design (it's like C #include directives), it Martin> breaks compatibility with The Way Things Have Always Been Martin> Done, so don't do it. lisp/term/ can be an exception, since Martin> nobody ever cares about the lisp here. Martin> It's possible you would also break things like find-function, Martin> i.e. any function that might examine load-path. OK, I can see that. I hate the fact, however, that mule/ lives under lisp/ --- it's not a true reflection of the dependencies here. It would be much more natural, IMHO, to have a mule-lisp/ directory alongside lisp/. Martin> That's not to say that file stat optimization isn't important. Martin> I suggest the following design: Martin> Add lisp/ with depth 1 to your list of lisp hierarchies. Martin> (when (featurep 'mule) Martin> Also add lisp/mule as another hierarchy of depth 1. Martin> I haven't looked at the code to see how hard this would be to Martin> implement. Don't worry about that---I'll do it, but I'd like to get it right. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

Re: Cannot install 21.2 from CVS after specifying --datadir 23 years, 10 months

Michael Sperber

>>>>> "Martin" == Martin Buchholz <martin(a)xemacs.org> writes: >>>>> "Vin" == Vin Shelton <acs(a)xemacs.org> writes: Vin> I thought the FSF / configure standard was that datadir was Vin> architecture-independent. Or was I just mistaken? Martin> You were correct. Martin> `datadir' Martin> The directory for installing read-only architecture independent Martin> data files. This should normally be `/usr/local/share', but write Martin> it as `$(prefix)/share'. (If you are using Autoconf, write it as Martin> `＠datadir＠'.) As a special exception, see `$(infodir)' and Martin> `$(includedir)' below. Sure, but this documentation does not apply for XEmacs, as I mentioned in another followup to Vin's question. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

Re: Cannot install 21.2 from CVS after specifying --datadir 23 years, 10 months

Vin Shelton

I don't know - I've lost access to CVS. I believe the firewall will be opened up sometime this week and I'll try again. I thought the FSF / configure standard was that datadir was architecture-independent. Or was I just mistaken? - vin sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: > >>>>> "Vin" == Vin Shelton <acs(a)xemacs.org> writes: > > Vin> I routinely build XEmacs here at work on SunOS-4.1.4 and SunOS-5.5 in > Vin> order to make sure no major breakage occurs between releases. I do > Vin> not have sufficient time to spend major hours on this, but it provides > Vin> a simple sanity check on 21.1 and 21.2 development status. > > Vin> Last week I decided it would be nice to share the > Vin> architecture-independent data directories between the 4.1 and 5.5 > Vin> builds. I have not been able to get this to work under 21.2 from CVS. > Vin> In order to accomplish this, I'm specifying --datadir to configure; > Vin> after doing this, 'make beta' and 'make check' work fine, but 'make > Vin> install' fails. Here's how: > > I have not been able to reproduce this with the current XEmacs from > CVS. Does it still occur? > > Moreover, note that --datadir will not do what you want: the directory > also includes architecture-dependent files. See this setting in > configure.in, for instance: > > archlibdir='${datadir}/${instvardir}/${configuration}' > > Having said that, I've found two other minor issues with specifying > datadir for which I'll submit a patch shortly. > > -- > Cheers =8-} Mike > Friede, V�lkerverst�ndigung und �berhaupt blabla > -- In a minute there is time For decisions and revisions which a minute will reverse. T.S. Eliot [URL: http://www.cs.amherst.edu/~ccm/prufrock.html]

2 participants
1 comments

auto-autoloads 23 years, 10 months

aviad lahav

hello everyone, i could not find any documentation about the auto-autoloads files. what are they and when and how are they loaded? thanks. נשלח ע"י משתמש Hotmail בעיברית. הצטרפו גם אתם לקהילת MSN ישראל. http://www.msn.co.il

1 participants
0 comments

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

XEmacs-Beta January 2001