* 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: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
* 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
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.