* Two problems of building Emacs on windows @ 2007-10-19 8:25 Herbert Euler 2007-10-19 11:24 ` Eli Zaretskii 0 siblings, 1 reply; 7+ messages in thread From: Herbert Euler @ 2007-10-19 8:25 UTC (permalink / raw) To: emacs-devel [-- Attachment #1.1: Type: text/plain, Size: 1639 bytes --] I have two problems building Emacs (the unicode-2 branch) on Windows, described below. 1. On missing of some subr's documentations. Here is the error when I require help information about some subrs: C-h f string RET ==> string is a built-in function in `C source code'. [Missing arglist. Please make a bug report.] Not documented. In fact, all subr's in character.c miss their documentations. Well, I do not know whether this problem exists before, but adding `character.o' to the definition of the `obj' variable in nt\makefile.w32-in solves this. (I did not check whether other files are missing though.) 2. On `buildobj.lst'. Because the different building directories arrangement on Windows, `buildobj.lst' can't be found correctly when the executable emacs.exe is dumped. It is in the `etc' directory on GNU/Linux for example, but not there on Windows. In my building, it is in `src/oo-spd/i386'. To fix the errors in dumping, I did these manually: - Copy the file `buildobj.lst' from `$(OBJDIR)/$(ARCH)' to `$(OBJDIR)/etc'. - Create the directory `$(OBJDIR)/lib-src'. This will make Emacs set `installation-directory' to where it is invoked when dumping (i.e. `$(OBJDIR)/etc', but rather `c:/emacs/etc' in nt/paths.h). See also `init_cmdargs' in emacs.c. I guess the makefiles need fixing. Regards, Guanpeng Xu _________________________________________________________________ Connect to the next generation of MSN Messenger http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source=wlmailtagline [-- Attachment #1.2: Type: text/html, Size: 2159 bytes --] [-- Attachment #2: Type: text/plain, Size: 142 bytes --] _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Two problems of building Emacs on windows 2007-10-19 8:25 Two problems of building Emacs on windows Herbert Euler @ 2007-10-19 11:24 ` Eli Zaretskii 2007-10-19 11:45 ` Jason Rumney 2007-10-19 12:04 ` Herbert Euler 0 siblings, 2 replies; 7+ messages in thread From: Eli Zaretskii @ 2007-10-19 11:24 UTC (permalink / raw) To: Herbert Euler; +Cc: emacs-devel > From: Herbert Euler <herberteuler@hotmail.com> > Date: Fri, 19 Oct 2007 16:25:50 +0800 > > 2. On `buildobj.lst'. > > Because the different building directories arrangement on Windows, > `buildobj.lst' can't be found correctly when the executable emacs.exe > is dumped. It is in the `etc' directory on GNU/Linux for example, but > not there on Windows. Why do you need this file after Emacs is dumped? ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Two problems of building Emacs on windows 2007-10-19 11:24 ` Eli Zaretskii @ 2007-10-19 11:45 ` Jason Rumney 2007-10-19 12:09 ` Herbert Euler 2007-10-19 12:04 ` Herbert Euler 1 sibling, 1 reply; 7+ messages in thread From: Jason Rumney @ 2007-10-19 11:45 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Herbert Euler, emacs-devel Eli Zaretskii wrote: > Why do you need this file after Emacs is dumped? > You don't. Stefan moved the file's location as part of the emacs-unicode merge, since he was having trouble with it, and noticed it was in a different location than the DOC file to which it relates. However, when emacs is dumped, it uses the hardcoded paths in epaths.h on Windows (I'm not sure why this is not the case on GNU/Linux), so even if the same changes are made to makefile.w32-in as were made to Makefile.in the build will only work if emacs is built from c:/emacs. The solution for buildobj.lst is to undo the change that Stefan made, then investigate the problem that caused him to make that change (if the problem is still there). ^ permalink raw reply [flat|nested] 7+ messages in thread
* RE: Two problems of building Emacs on windows 2007-10-19 11:45 ` Jason Rumney @ 2007-10-19 12:09 ` Herbert Euler 2007-10-19 12:11 ` Herbert Euler 2007-10-20 23:51 ` Jason Rumney 0 siblings, 2 replies; 7+ messages in thread From: Herbert Euler @ 2007-10-19 12:09 UTC (permalink / raw) To: Jason Rumney, Eli Zaretskii; +Cc: emacs-devel [-- Attachment #1.1: Type: text/plain, Size: 870 bytes --] > However, when > emacs is dumped, it uses the hardcoded paths in epaths.h on Windows (I'm > not sure why this is not the case on GNU/Linux), This is exactly because the existence of `lib-src' in the same directory where `etc' exists: please read `init_cmdargs' in main.c. The inexistence causes Emacs not setting `installation-directory' to a proper value but leaving it nil, so later in the Emacs' starting up process `doc-directory' is left the one in nt\paths.h. If you create `lib-src' in $(OBJDIR) and copy the file buildobj.lst into etc, it will not use the "hardcoded paths" and use the correct path instead. Regards, Guanpeng Xu _________________________________________________________________ Connect to the next generation of MSN Messenger http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source=wlmailtagline [-- Attachment #1.2: Type: text/html, Size: 1092 bytes --] [-- Attachment #2: Type: text/plain, Size: 142 bytes --] _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel ^ permalink raw reply [flat|nested] 7+ messages in thread
* RE: Two problems of building Emacs on windows 2007-10-19 12:09 ` Herbert Euler @ 2007-10-19 12:11 ` Herbert Euler 2007-10-20 23:51 ` Jason Rumney 1 sibling, 0 replies; 7+ messages in thread From: Herbert Euler @ 2007-10-19 12:11 UTC (permalink / raw) To: Jason Rumney, Eli Zaretskii; +Cc: emacs-devel [-- Attachment #1.1: Type: text/plain, Size: 1189 bytes --] Sorry, should be "the inexistence of `lib-src' in the same directory where `etc' exists". Regards, Guanpeng Xu From: herberteuler@hotmail.com To: jasonr@gnu.org; eliz@gnu.org Date: Fri, 19 Oct 2007 20:09:26 +0800 CC: emacs-devel@gnu.org Subject: RE: Two problems of building Emacs on windows > However, when > emacs is dumped, it uses the hardcoded paths in epaths.h on Windows (I'm > not sure why this is not the case on GNU/Linux), This is exactly because the existence of `lib-src' in the same directory where `etc' exists: please read `init_cmdargs' in main.c. The inexistence causes Emacs not setting `installation-directory' to a proper value but leaving it nil, so later in the Emacs' starting up process `doc-directory' is left the one in nt\paths.h. If you create `lib-src' in $(OBJDIR) and copy the file buildobj.lst into etc, it will not use the "hardcoded paths" and use the correct path instead. Regards, Guanpeng Xu Connect to the next generation of MSN Messenger Get it now! _________________________________________________________________ Explore the seven wonders of the world http://search.msn.com/results.aspx?q=7+wonders+world&mkt=en-US&form=QBRE [-- Attachment #1.2: Type: text/html, Size: 1615 bytes --] [-- Attachment #2: Type: text/plain, Size: 142 bytes --] _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Two problems of building Emacs on windows 2007-10-19 12:09 ` Herbert Euler 2007-10-19 12:11 ` Herbert Euler @ 2007-10-20 23:51 ` Jason Rumney 1 sibling, 0 replies; 7+ messages in thread From: Jason Rumney @ 2007-10-20 23:51 UTC (permalink / raw) To: Herbert Euler; +Cc: Eli Zaretskii, emacs-devel Herbert Euler wrote: > This is exactly because the existence of `lib-src' in the same directory > where `etc' exists: please read `init_cmdargs' in main.c. The inexistence > causes Emacs not setting `installation-directory' to a proper value but > leaving it nil, so later in the Emacs' starting up process `doc-directory' > is left the one in nt\paths.h. > > If you create `lib-src' in $(OBJDIR) and copy the file buildobj.lst > into etc, > it will not use the "hardcoded paths" and use the correct path instead. I see. I've restored the original code that creates buildobj.lst in the src target directory, but the above may still be an undetected problem for other files, so I'll investigate whether a fix is required in the emacs-22 branch before making any changes in unicode-2. ^ permalink raw reply [flat|nested] 7+ messages in thread
* RE: Two problems of building Emacs on windows 2007-10-19 11:24 ` Eli Zaretskii 2007-10-19 11:45 ` Jason Rumney @ 2007-10-19 12:04 ` Herbert Euler 1 sibling, 0 replies; 7+ messages in thread From: Herbert Euler @ 2007-10-19 12:04 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel [-- Attachment #1.1: Type: text/plain, Size: 2416 bytes --] > > 2. On `buildobj.lst'. > > > > Because the different building directories arrangement on Windows, > > `buildobj.lst' can't be found correctly when the executable emacs.exe > > is dumped. It is in the `etc' directory on GNU/Linux for example, but > > not there on Windows. > > Why do you need this file after Emacs is dumped? Sure I don't need it after Emacs is dumped. The problem is that I can't dump it. Let me explain it more precisely. At least in my building, the C parts of Emacs is built in $(OBJDIR)/$(ARCH), i.e. src/oo-spd/i386. Then the file DOC-X is put into $(OBJDIR)/etc, i.e. src/oo-spd/etc. The file buildobj.lst is in src/oo-spd/i386. There is only one file, DOC-X, in src/oo-spd/etc. Dumping Emacs requires buildobj.lst, and it should be in some directory named `etc'. This directory could be the top-level etc directory in the source code, or where the C parts is actually built (e.g. src/oo-spd/etc), depends on the value of `doc-directory' (please see the definition of Snarf-documentation, which does the job of reading "buildobj.lst"). Unfornately, buildobj.lst is in neither of these directories. But just copying it to src/oo-spd/etc is not sufficient. In the building process, `doc-directory' should be re-computed in time, but not use the value in nt/paths.h. The code that computes this variable is in `init_callproc' in callproc.c. As we can see, it will be re-computed only when `installation-directory' is non-nil, which is changed to a non-nil value in `init_cmdargs' in emacs.c in some cases. But there is a prerequisite on that: the building directory must contains both `lib-src' as well as `etc' in its parent directory, and the existence of `lib-src' is tested before `etc'. If `lib-src' does not exist, then `installation-directory' is nil, no matter whether `etc' exists in that directory (`init_cmdargs' in main.c). In my building, there is only src/oo-spd/etc, so in addition to copying buildobj.lst from src/oo-spd/i386 to src/oo-spd/etc, I have to create src/oo-spd/lib-src as well. Btw, is it because I did not build Emacs in a standard way so I encounter these errors? Regards, Guanpeng Xu _________________________________________________________________ Connect to the next generation of MSN Messenger http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source=wlmailtagline [-- Attachment #1.2: Type: text/html, Size: 2791 bytes --] [-- Attachment #2: Type: text/plain, Size: 142 bytes --] _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2007-10-20 23:51 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2007-10-19 8:25 Two problems of building Emacs on windows Herbert Euler 2007-10-19 11:24 ` Eli Zaretskii 2007-10-19 11:45 ` Jason Rumney 2007-10-19 12:09 ` Herbert Euler 2007-10-19 12:11 ` Herbert Euler 2007-10-20 23:51 ` Jason Rumney 2007-10-19 12:04 ` Herbert Euler
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.