* Pretest
@ 2006-10-27 17:59 Chong Yidong
2006-10-27 18:52 ` Pretest Paul Pogonyshev
` (17 more replies)
0 siblings, 18 replies; 172+ messages in thread
From: Chong Yidong @ 2006-10-27 17:59 UTC (permalink / raw)
With Richard's agreement, I've bumped the version number to 22.0.90
and rolled a pretest tarball. The tarball can be found at
ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-22.0.90.tar.gz
Since Leim has been merged into Emacs, there is no separate
leim-22.0.90.tar.gz (I'll update admin/make-announcement to reflect
this).
Since this is the first Emacs 22 pretest tarball, it would be nice if
people could take a look and make sure there are no problems building
from, before we think about making any pretest announcement.
If no problems are found, I guess we can proceed with the pretest.
According to admin/make-tarball, RMS is supposed to announce it to the
list of emacs pretesters; here is the canned announcement generated by
admin/make-announcement:
There is a new pretest available in
ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-22.0.90.tar.gz
Please report results from compiling and running the pretest to
<emacs-pretest-bug@gnu.org>. Your feedback is necessary for us
to know on which platforms the pretest has been tried.
(I took out some additional info about xdelta's between this tarball
and the previous pretest tarball, because there is no previous
tarball).
The question is, who do we announce the pretest to? Is the emacs
pretesters mailing list still extant? If not, I think we should just
make a public announcement about the availability of the pretest
tarball on the Gnu Emacs webpage. We could also contact distributions
such as Debian, which package occasional CVS snapshots of Emacs 22, to
switch to tracking the numbered pretest tarballs for those packages
instead.
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-10-27 17:59 Pretest Chong Yidong
@ 2006-10-27 18:52 ` Paul Pogonyshev
2006-10-27 19:12 ` Pretest David Hansen
` (16 subsequent siblings)
17 siblings, 0 replies; 172+ messages in thread
From: Paul Pogonyshev @ 2006-10-27 18:52 UTC (permalink / raw)
Chong Yidong wrote:
> With Richard's agreement, I've bumped the version number to 22.0.90
> and rolled a pretest tarball. [...]
At last! Thanks.
Paul
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-10-27 17:59 Pretest Chong Yidong
2006-10-27 18:52 ` Pretest Paul Pogonyshev
@ 2006-10-27 19:12 ` David Hansen
2006-10-28 11:31 ` Pretest Eli Zaretskii
2006-10-27 19:38 ` Pretest Kim F. Storm
` (15 subsequent siblings)
17 siblings, 1 reply; 172+ messages in thread
From: David Hansen @ 2006-10-27 19:12 UTC (permalink / raw)
On Fri, 27 Oct 2006 13:59:36 -0400 Chong Yidong wrote:
> The question is, who do we announce the pretest to? Is the emacs
> pretesters mailing list still extant? If not, I think we should just
> make a public announcement about the availability of the pretest
> tarball on the Gnu Emacs webpage.
As there are already a lot of "normal" users out there who use
Emacs 22 for daily work why not gnu.emacs.help?
David
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-10-27 17:59 Pretest Chong Yidong
2006-10-27 18:52 ` Pretest Paul Pogonyshev
2006-10-27 19:12 ` Pretest David Hansen
@ 2006-10-27 19:38 ` Kim F. Storm
2006-10-28 11:17 ` Pretest Eli Zaretskii
2006-10-27 20:01 ` Pretest joakim
` (14 subsequent siblings)
17 siblings, 1 reply; 172+ messages in thread
From: Kim F. Storm @ 2006-10-27 19:38 UTC (permalink / raw)
Cc: emacs-devel
Chong Yidong <cyd@stupidchicken.com> writes:
> With Richard's agreement, I've bumped the version number to 22.0.90
> and rolled a pretest tarball. The tarball can be found at
>
> ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-22.0.90.tar.gz
Thanks Chong! This is excellent news!!!
It builds and runs on my GNU/Linux (redhat 9.0) laptop.
> (I took out some additional info about xdelta's between this tarball
> and the previous pretest tarball, because there is no previous
> tarball).
I wonder if we really need to provide xdeltas anymore.
For most people there days, the time it takes to get them working (I
remember having problems with the last pretest ...) compared to the
time it takes to simply download a new tarball doesn't warrent the
time needed to make them...
> The question is, who do we announce the pretest to? Is the emacs
> pretesters mailing list still extant?
I think so.
> If not, I think we should just
> make a public announcement about the availability of the pretest
> tarball on the Gnu Emacs webpage.
comp.emacs, gnu.announce, and gnu.emacs.announce seem to be good places...
> We could also contact distributions
> such as Debian, which package occasional CVS snapshots of Emacs 22, to
> switch to tracking the numbered pretest tarballs for those packages
> instead.
I don't know what's best here, but I'd wait until we have have another
pretest or the final release.
--
Kim F. Storm <storm@cua.dk> http://www.cua.dk
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-10-27 17:59 Pretest Chong Yidong
` (2 preceding siblings ...)
2006-10-27 19:38 ` Pretest Kim F. Storm
@ 2006-10-27 20:01 ` joakim
2006-10-27 21:11 ` Pretest Giorgos Keramidas
` (13 subsequent siblings)
17 siblings, 0 replies; 172+ messages in thread
From: joakim @ 2006-10-27 20:01 UTC (permalink / raw)
Chong Yidong <cyd@stupidchicken.com> writes:
builds and runs ok on the following plattform:
Linux kurono.home 2.6.17-1.2142_FC4 #1 Tue Jul 11 22:41:06 EDT 2006 x86_64 x86_64 x86_64 GNU/Linux
> With Richard's agreement, I've bumped the version number to 22.0.90
> and rolled a pretest tarball. The tarball can be found at
>
> ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-22.0.90.tar.gz
>
> Since Leim has been merged into Emacs, there is no separate
> leim-22.0.90.tar.gz (I'll update admin/make-announcement to reflect
> this).
>
> Since this is the first Emacs 22 pretest tarball, it would be nice if
> people could take a look and make sure there are no problems building
> from, before we think about making any pretest announcement.
>
>
> If no problems are found, I guess we can proceed with the pretest.
> According to admin/make-tarball, RMS is supposed to announce it to the
> list of emacs pretesters; here is the canned announcement generated by
> admin/make-announcement:
>
> There is a new pretest available in
>
> ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-22.0.90.tar.gz
>
> Please report results from compiling and running the pretest to
> <emacs-pretest-bug@gnu.org>. Your feedback is necessary for us
> to know on which platforms the pretest has been tried.
>
> (I took out some additional info about xdelta's between this tarball
> and the previous pretest tarball, because there is no previous
> tarball).
>
>
> The question is, who do we announce the pretest to? Is the emacs
> pretesters mailing list still extant? If not, I think we should just
> make a public announcement about the availability of the pretest
> tarball on the Gnu Emacs webpage. We could also contact distributions
> such as Debian, which package occasional CVS snapshots of Emacs 22, to
> switch to tracking the numbered pretest tarballs for those packages
> instead.
--
Joakim Verona
http://www.verona.se
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-10-27 17:59 Pretest Chong Yidong
` (3 preceding siblings ...)
2006-10-27 20:01 ` Pretest joakim
@ 2006-10-27 21:11 ` Giorgos Keramidas
2006-10-28 2:30 ` Pretest Andrew M. Scott
` (12 subsequent siblings)
17 siblings, 0 replies; 172+ messages in thread
From: Giorgos Keramidas @ 2006-10-27 21:11 UTC (permalink / raw)
Cc: emacs-devel
On 2006-10-27 13:59, Chong Yidong <cyd@stupidchicken.com> wrote:
> With Richard's agreement, I've bumped the version number to 22.0.90
> and rolled a pretest tarball. The tarball can be found at
>
> ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-22.0.90.tar.gz
>
> Since Leim has been merged into Emacs, there is no separate
> leim-22.0.90.tar.gz (I'll update admin/make-announcement to reflect
> this).
>
> Since this is the first Emacs 22 pretest tarball, it would be nice if
> people could take a look and make sure there are no problems building
> from, before we think about making any pretest announcement.
Compiled successfully, installed and running fine as my editor for this
message and as another, X11 instance (with Lucid widgets) on:
$ uname -a
FreeBSD gothmog.pc 7.0-CURRENT FreeBSD 7.0-CURRENT #1: \
Mon Oct 23 13:35:35 EEST 2006 \
build@gothmog.pc:/home/build/obj/home/build/src/sys/GOTHMOG i386
$
I haven't tried a GTK+-enabled build yet. It should be easy to do this
early tomorrow morning too.
Thanks again, to all the people who brought this Emacs version to us :)
- Giorgos
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-10-27 17:59 Pretest Chong Yidong
` (4 preceding siblings ...)
2006-10-27 21:11 ` Pretest Giorgos Keramidas
@ 2006-10-28 2:30 ` Andrew M. Scott
2006-10-28 8:11 ` Pretest Yoni Rabkin Katzenell
` (11 subsequent siblings)
17 siblings, 0 replies; 172+ messages in thread
From: Andrew M. Scott @ 2006-10-28 2:30 UTC (permalink / raw)
Thanks!
Chong> With Richard's agreement, I've bumped the version number to
Chong> 22.0.90 and rolled a pretest tarball. The tarball can be
Chong> found at
Chong> ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-22.0.90.tar.gz
Chong> Since this is the first Emacs 22 pretest tarball, it would
Chong> be nice if people could take a look and make sure there are
Chong> no problems building from, before we think about making any
Chong> pretest announcement.
It builds fine for me:
In GNU Emacs 22.0.90.1 (x86_64-unknown-linux-gnu, X toolkit)
of 2006-10-27 on chlr6708
SUSE LINUX Enterprise Server 9 (x86_64)
VERSION = 9
PATCHLEVEL = 3
FYI, I had to recompile the ancillary package emacs-w3m and its
associated APEL and FLIM libraries due to the the emacs numerical
incremention, e.g.:
Old: <installation path>/share/emacs/22.0.50/site-lisp/emu/
New: <installation path>/share/emacs/22.0.90/site-lisp/emu/
Andy Scott
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-10-27 17:59 Pretest Chong Yidong
` (5 preceding siblings ...)
2006-10-28 2:30 ` Pretest Andrew M. Scott
@ 2006-10-28 8:11 ` Yoni Rabkin Katzenell
2006-10-28 8:46 ` Pretest Andreas Roehler
` (10 subsequent siblings)
17 siblings, 0 replies; 172+ messages in thread
From: Yoni Rabkin Katzenell @ 2006-10-28 8:11 UTC (permalink / raw)
Chong Yidong <cyd@stupidchicken.com> writes:
> Since this is the first Emacs 22 pretest tarball, it would be nice if
> people could take a look and make sure there are no problems building
> from, before we think about making any pretest announcement.
Compiles and seems to be working:
GNU Emacs 22.0.90.1 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
Linux 2.6.8-2-386 #1 Tue Aug 16 12:46:35 UTC 2005 i686 GNU/Linux
Linux 2.6.17-10-386 #2 Fri Oct 13 18:41:40 UTC 2006 i686 GNU/Linux
--
"Cut your own wood and it will warm you twice"
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-10-27 17:59 Pretest Chong Yidong
` (6 preceding siblings ...)
2006-10-28 8:11 ` Pretest Yoni Rabkin Katzenell
@ 2006-10-28 8:46 ` Andreas Roehler
2006-10-28 11:01 ` Pretest Jason Rumney
` (9 subsequent siblings)
17 siblings, 0 replies; 172+ messages in thread
From: Andreas Roehler @ 2006-10-28 8:46 UTC (permalink / raw)
Cc: emacs-devel
Thanks a lot.
Everything seems fine at
SuSE linux 10.0
GNU Emacs 22.0.90.1 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
BTW: emacs-w3m runs out of the box.
__
Andreas Roehler
Chong Yidong schrieb:
> With Richard's agreement, I've bumped the version number to 22.0.90
> and rolled a pretest tarball. The tarball can be found at
>
> ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-22.0.90.tar.gz
>
> Since Leim has been merged into Emacs, there is no separate
> leim-22.0.90.tar.gz (I'll update admin/make-announcement to reflect
> this).
>
> Since this is the first Emacs 22 pretest tarball, it would be nice if
> people could take a look and make sure there are no problems building
> from, before we think about making any pretest announcement.
>
>
> If no problems are found, I guess we can proceed with the pretest.
> According to admin/make-tarball, RMS is supposed to announce it to the
> list of emacs pretesters; here is the canned announcement generated by
> admin/make-announcement:
>
> There is a new pretest available in
>
> ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-22.0.90.tar.gz
>
> Please report results from compiling and running the pretest to
> <emacs-pretest-bug@gnu.org>. Your feedback is necessary for us
> to know on which platforms the pretest has been tried.
>
> (I took out some additional info about xdelta's between this tarball
> and the previous pretest tarball, because there is no previous
> tarball).
>
>
> The question is, who do we announce the pretest to? Is the emacs
> pretesters mailing list still extant? If not, I think we should just
> make a public announcement about the availability of the pretest
> tarball on the Gnu Emacs webpage. We could also contact distributions
> such as Debian, which package occasional CVS snapshots of Emacs 22, to
> switch to tracking the numbered pretest tarballs for those packages
> instead.
>
>
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel
>
>
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-10-27 17:59 Pretest Chong Yidong
` (7 preceding siblings ...)
2006-10-28 8:46 ` Pretest Andreas Roehler
@ 2006-10-28 11:01 ` Jason Rumney
2006-10-28 13:14 ` Pretest Eli Zaretskii
2006-10-28 11:13 ` Pretest Eli Zaretskii
` (8 subsequent siblings)
17 siblings, 1 reply; 172+ messages in thread
From: Jason Rumney @ 2006-10-28 11:01 UTC (permalink / raw)
Cc: emacs-devel
On a fresh install with w32, I got the following error:
gcc -I. -DWIN32_LEAN_AND_MEAN -D_WIN32_WINNT=0x0400 -D_X86_=1 -c
-gstabs+ -g3 -mtune=pentium4 -O2 -Di386 -D_CRTAPI1=_cdecl
-DWINDOWSNT -DDOS_NT -DSTDC_HEADERS=1 -DNO_LDAV=1 -DNO_ARCHIVES=1
-DHAVE_CONFIG_H=1 -I../nt/inc -I../src -o oo-spd/i386/digest-doc.o
digest-doc.c
gcc -o oo-spd/i386/digest-doc.exe -gstabs+ -g3
oo-spd/i386/digest-doc.o -ladvapi32
mingw32-make[1]: *** No rule to make target
`../src/oo-spd/i386/temacs.exe', needed by `DOC'. Stop.
mingw32-make[1]: Leaving directory `C:/emacs-22.0.90/lib-src'
mingw32-make: *** [all-other-dirs-gmake] Error 2
I'll look into it, and see if it is a configuration problem with this
PC, or a problem with the makefiles that has gone undetected.
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-10-27 17:59 Pretest Chong Yidong
` (8 preceding siblings ...)
2006-10-28 11:01 ` Pretest Jason Rumney
@ 2006-10-28 11:13 ` Eli Zaretskii
2006-10-28 13:30 ` Pretest Benjamin Riefenstahl
` (7 subsequent siblings)
17 siblings, 0 replies; 172+ messages in thread
From: Eli Zaretskii @ 2006-10-28 11:13 UTC (permalink / raw)
Cc: emacs-devel
> From: Chong Yidong <cyd@stupidchicken.com>
> Date: Fri, 27 Oct 2006 13:59:36 -0400
>
> With Richard's agreement, I've bumped the version number to 22.0.90
> and rolled a pretest tarball. The tarball can be found at
>
> ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-22.0.90.tar.gz
Thanks! Downloading it as we speak.
> The question is, who do we announce the pretest to?
To the Emacs pretesters.
> Is the emacs pretesters mailing list still extant?
Yes.
I think the announcement should also go to emacs-devel.
> If not, I think we should just make a public announcement about the
> availability of the pretest tarball on the Gnu Emacs webpage. We
> could also contact distributions such as Debian, which package
> occasional CVS snapshots of Emacs 22, to switch to tracking the
> numbered pretest tarballs for those packages instead.
These should all be tracking emacs-devel and emacs-pretest-bug anyway,
if they want to be up-to-date with Emacs development and known bugs.
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-10-27 19:38 ` Pretest Kim F. Storm
@ 2006-10-28 11:17 ` Eli Zaretskii
2006-10-29 18:45 ` Pretest Richard Stallman
0 siblings, 1 reply; 172+ messages in thread
From: Eli Zaretskii @ 2006-10-28 11:17 UTC (permalink / raw)
Cc: cyd, emacs-devel
> From: storm@cua.dk (Kim F. Storm)
> Date: Fri, 27 Oct 2006 21:38:01 +0200
> Cc: emacs-devel@gnu.org
>
> I wonder if we really need to provide xdeltas anymore.
Why not? The Emacs tarball is significantly larger now than in
previous versions (because Calc, Leim, ELisp, and Lisp Intro are now
parts of it), so downloading a full tarball might be a pain.
> For most people there days, the time it takes to get them working (I
> remember having problems with the last pretest ...) compared to the
> time it takes to simply download a new tarball doesn't warrent the
> time needed to make them...
If you have a fast connection, yes. But not everyone has it.
> > If not, I think we should just
> > make a public announcement about the availability of the pretest
> > tarball on the Gnu Emacs webpage.
>
> comp.emacs, gnu.announce, and gnu.emacs.announce seem to be good places...
We never published pretests on those fori, only the official
releases. Why should we change the policy now, that everyone who is
interested can read emacs-devel anyway?
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-10-27 19:12 ` Pretest David Hansen
@ 2006-10-28 11:31 ` Eli Zaretskii
2006-11-15 21:35 ` Pretest Reiner Steib
0 siblings, 1 reply; 172+ messages in thread
From: Eli Zaretskii @ 2006-10-28 11:31 UTC (permalink / raw)
Cc: emacs-devel
> From: David Hansen <david.hansen@gmx.net>
> Date: Fri, 27 Oct 2006 21:12:03 +0200
>
> As there are already a lot of "normal" users out there who use
> Emacs 22 for daily work why not gnu.emacs.help?
If they already use the CVS code, they don't need the announcement, do
they?
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-10-28 11:01 ` Pretest Jason Rumney
@ 2006-10-28 13:14 ` Eli Zaretskii
2006-10-28 21:47 ` Pretest Jason Rumney
0 siblings, 1 reply; 172+ messages in thread
From: Eli Zaretskii @ 2006-10-28 13:14 UTC (permalink / raw)
Cc: cyd, emacs-devel
> Date: Sat, 28 Oct 2006 12:01:50 +0100
> From: Jason Rumney <jasonr@gnu.org>
> Cc: emacs-devel@gnu.org
>
> On a fresh install with w32, I got the following error:
>
>
> gcc -I. -DWIN32_LEAN_AND_MEAN -D_WIN32_WINNT=0x0400 -D_X86_=1 -c
> -gstabs+ -g3 -mtune=pentium4 -O2 -Di386 -D_CRTAPI1=_cdecl
> -DWINDOWSNT -DDOS_NT -DSTDC_HEADERS=1 -DNO_LDAV=1 -DNO_ARCHIVES=1
> -DHAVE_CONFIG_H=1 -I../nt/inc -I../src -o oo-spd/i386/digest-doc.o
> digest-doc.c
> gcc -o oo-spd/i386/digest-doc.exe -gstabs+ -g3
> oo-spd/i386/digest-doc.o -ladvapi32
> mingw32-make[1]: *** No rule to make target
> `../src/oo-spd/i386/temacs.exe', needed by `DOC'. Stop.
> mingw32-make[1]: Leaving directory `C:/emacs-22.0.90/lib-src'
> mingw32-make: *** [all-other-dirs-gmake] Error 2
>
>
> I'll look into it, and see if it is a configuration problem with this
> PC, or a problem with the makefiles that has gone undetected.
It's a real bug, it happens the first time a source tree is compiled.
Please try the patch below. I will check it in if there are no
objections.
diff -u "emacs-pretest/emacs-22.0.90/lib-src/makefile.w32-in~" "emacs-pretest/emacs-22.0.90/lib-src/makefile.w32-in"
--- emacs-pretest/emacs-22.0.90/lib-src/makefile.w32-in~ 2006-10-10 21:01:30.000000000 +0200
+++ emacs-pretest/emacs-22.0.90/lib-src/makefile.w32-in 2006-10-28 15:08:33.420500000 +0200
@@ -263,6 +263,13 @@
$(lispsource)window.elc \
$(lispsource)version.el
+# This is needed the first time we build the tree, since temacs.exe
+# does not exist yet, and the DOC rule needs it to rebuild DOC whenever
+# Emacs is rebuilt.
+../src/$(BLD)/temacs.exe:
+ - mkdir "../src/$(OBJDIR)"
+ - mkdir "../src/$(BLD)"
+ @echo temacs > $@
DOC = DOC
$(DOC): $(BLD) $(BLD)/make-docfile.exe ../src/$(BLD)/temacs.exe $(lisp1) $(lisp2)
Diff finished. Sat Oct 28 15:11:59 2006
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-10-27 17:59 Pretest Chong Yidong
` (9 preceding siblings ...)
2006-10-28 11:13 ` Pretest Eli Zaretskii
@ 2006-10-28 13:30 ` Benjamin Riefenstahl
2006-10-28 15:25 ` Pretest Chong Yidong
2006-10-28 13:38 ` Pretest Eli Zaretskii
` (6 subsequent siblings)
17 siblings, 1 reply; 172+ messages in thread
From: Benjamin Riefenstahl @ 2006-10-28 13:30 UTC (permalink / raw)
Cc: emacs-devel
Hi,
Chong Yidong writes:
> I've bumped the version number to 22.0.90 and rolled a pretest
> tarball.
Cool.
> it would be nice if people could take a look and make sure there are
> no problems building from,
Building on Mac OS X (10.3), "make" fails with (last lines only):
Writing LC_UNIXTHREAD command
26524 unused bytes follow Mach-O header
1099612 pure bytes used
./emacs -q -batch -f list-load-path-shadows
make[1]: *** No rule to make target `/Users/benny/Projects/emacs-22.0.90/src/../mac/Emacs.app/Contents/Resources/Emacs.icns', needed by `macosx-bundle'. Stop.
make: *** [src] Error 2
It seems that mac/Emacs.app/Contents/Resources/Emacs.icns is missing.
After I copy the file from a CVS checkout, "make" proceeds and the
result of "make install" seems to work fine.
benny
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-10-27 17:59 Pretest Chong Yidong
` (10 preceding siblings ...)
2006-10-28 13:30 ` Pretest Benjamin Riefenstahl
@ 2006-10-28 13:38 ` Eli Zaretskii
2006-10-28 15:53 ` Pretest Chong Yidong
2006-10-28 14:28 ` Pretest Eli Zaretskii
` (5 subsequent siblings)
17 siblings, 1 reply; 172+ messages in thread
From: Eli Zaretskii @ 2006-10-28 13:38 UTC (permalink / raw)
Cc: emacs-devel
> From: Chong Yidong <cyd@stupidchicken.com>
> Date: Fri, 27 Oct 2006 13:59:36 -0400
>
> Since this is the first Emacs 22 pretest tarball, it would be nice if
> people could take a look and make sure there are no problems building
> from, before we think about making any pretest announcement.
With the exception of the single bug reported by Jason (to which I
posted a suggested solution), this pretest builds on Windows XP and
identifies itself as follows:
GNU Emacs 22.0.90.1 (i386-mingw-nt5.1.2600) of 2006-10-28
I found two (possibly related) problems in the Info files included in
this pretest:
. The first line of some of the Info file cites its full absolute
file name on your machine, like this:
This is /home/cyd/emacs/lispintro/../info/eintr, produced by makeinfo
version 4.8 from /home/cyd/emacs/lispintro/emacs-lisp-intro.texi.
I'm sure you didn't want to publish the directory tree of your
machine ;-)
I don't know how this happened, especially since some of the files
have the correct text:
This is ../info/emacs, produced by makeinfo version 4.8 from emacs.texi.
. The file info/emacs-xtra was produced incorrectly: it includes all
the stuff that should only be in the printed version, and is
therefore conditioned by @iftex. I have no other clue to this
mystery except that the fact that it was somehow produced by a
different version of Makeinfo:
This is ../info/emacs-xtra, produced by makeinfo version 4.7 from
emacs-xtra.texi.
(A few other files are built by makeinfo 4.7 as well.)
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-10-27 17:59 Pretest Chong Yidong
` (11 preceding siblings ...)
2006-10-28 13:38 ` Pretest Eli Zaretskii
@ 2006-10-28 14:28 ` Eli Zaretskii
2006-10-28 15:01 ` Pretest Chong Yidong
[not found] ` <cyd@stupidchicken.com>
` (4 subsequent siblings)
17 siblings, 1 reply; 172+ messages in thread
From: Eli Zaretskii @ 2006-10-28 14:28 UTC (permalink / raw)
> From: Chong Yidong <cyd@stupidchicken.com>
> Date: Fri, 27 Oct 2006 13:59:36 -0400
>
> Since this is the first Emacs 22 pretest tarball, it would be nice if
> people could take a look and make sure there are no problems building
> from, before we think about making any pretest announcement.
On this system:
Linux fencepost 2.6.12-fencepost #1 SMP Wed Jul 19 10:55:11 EDT 2006 i686 GNU/Linux
I cannot build the pretest: it fails while linking temacs. Here's the
last portion of the build transcript:
gcc -c -D_BSD_SOURCE -Demacs -DHAVE_CONFIG_H -I. -I/home/e/eliz/emacs.cvs/pretest/emacs-22.0.90/src -D_BSD_SOURCE -g -O2 terminfo.c
gcc -c -D_BSD_SOURCE -Demacs -DHAVE_CONFIG_H -I. -I/home/e/eliz/emacs.cvs/pretest/emacs-22.0.90/src -D_BSD_SOURCE -g -O2 lastfile.c
gcc -c -D_BSD_SOURCE -Demacs -DHAVE_CONFIG_H -I. -I/home/e/eliz/emacs.cvs/pretest/emacs-22.0.90/src -D_BSD_SOURCE -g -O2 vm-limit.c
gcc -c -D_BSD_SOURCE -Demacs -DHAVE_CONFIG_H -I. -I/home/e/eliz/emacs.cvs/pretest/emacs-22.0.90/src -D_BSD_SOURCE -g -O2 mktime.c
gcc -Demacs -DHAVE_CONFIG_H -I. -I/home/e/eliz/emacs.cvs/pretest/emacs-22.0.90/src -D_BSD_SOURCE -g -O2 -Wl,-znocombreloc /home/e/eliz/emacs.cvs/pretest/emacs-22.0.90/src/prefix-args.c -o prefix-args
echo "dispnew.o frame.o scroll.o xdisp.o xmenu.o window.o charset.o coding.o category.o ccl.o cm.o term.o xfaces.o emacs.o keyboard.o macros.o keymap.o sysdep.o buffer.o filelock.o insdel.o marker.o minibuf.o fileio.o dired.o filemode.o cmds.o casetab.o casefiddle.o indent.o search.o regex.o undo.o alloc.o data.o doc.o editfns.o callint.o eval.o floatfns.o fns.o print.o lread.o abbrev.o syntax.o unexelf.o bytecode.o process.o callproc.o region-cache.o sound.o atimer.o doprnt.o strftime.o intervals.o textprop.o composite.o md5.o terminfo.o lastfile.o vm-limit.o mktime.o " > buildobj.lst
gcc -nostdlib `./prefix-args -Xlinker -z nocombreloc` -Wl,-znocombreloc -o temacs pre-crt0.o /usr/lib/crt1.o /usr/lib/crti.o dispnew.o frame.o scroll.o xdisp.o xmenu.o window.o charset.o coding.o category.o ccl.o cm.o term.o xfaces.o emacs.o keyboard.o macros.o keymap.o sysdep.o buffer.o filelock.o insdel.o marker.o minibuf.o fileio.o dired.o filemode.o cmds.o casetab.o casefiddle.o indent.o search.o regex.o undo.o alloc.o data.o doc.o editfns.o callint.o eval.o floatfns.o fns.o print.o lread.o abbrev.o syntax.o unexelf.o bytecode.o process.o callproc.o region-cache.o sound.o atimer.o doprnt.o strftime.o intervals.o textprop.o composite.o md5.o terminfo.o lastfile.o vm-limit.o mktime.o -lncurses
-lm -lgcc -lc -lgcc /usr/lib/crtn.o
collect2: ld returned 1 exit status
make[1]: *** [temacs] Error 1
make[1]: Leaving directory `/home/e/eliz/emacs.cvs/pretest/emacs-22.0.90/src'
make: *** [src] Error 2
It seems ld fails with no message to explain the failure. I tried to
add various verbosity switches, like -t and --verbose, to LDFLAGS, but
couldn't see anything that'd explain the problem. Does anyone know
how to get ld to tell more?
This machine uses GCC 3.3.5 (Debian 1:3.3.5-8ubuntu2.1) and ld version
2.15.
Interestingly, the same machine builds the CVS version just fine (and
has been doing that for a very long time).
FWIW, here are the results of configure (the fact that it doesn't find
X headers and libraries is expected, due to the way this machine is
configured):
Configured for `i686-pc-linux-gnu'.
Where should the build process find the source code? /home/e/eliz/emacs.cvs
/pretest/emacs-22.0.90
What operating system and machine description files should Emacs use?
`s/gnu-linux.h' and `m/intel386.h'
What compiler should emacs be built with? gcc -g -O2
Should Emacs use the GNU version of malloc? yes
(Using Doug Lea's new malloc from the GNU C Library.)
Should Emacs use a relocating allocator for buffers? yes
Should Emacs use mmap(2) for buffer allocation? no
What window system should Emacs use? none
What toolkit should Emacs use? none
Where do we find X Windows header files? NONE
Where do we find X Windows libraries? NONE
Does Emacs use -lXaw3d? no
Does Emacs use -lXpm? no
Does Emacs use -ljpeg? no
Does Emacs use -ltiff? no
Does Emacs use -lungif? no
Does Emacs use -lpng? no
Does Emacs use X toolkit scroll bars? no
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-10-28 14:28 ` Pretest Eli Zaretskii
@ 2006-10-28 15:01 ` Chong Yidong
2006-10-28 19:28 ` Pretest Eli Zaretskii
0 siblings, 1 reply; 172+ messages in thread
From: Chong Yidong @ 2006-10-28 15:01 UTC (permalink / raw)
Cc: emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Chong Yidong <cyd@stupidchicken.com>
>> Date: Fri, 27 Oct 2006 13:59:36 -0400
>>
>> Since this is the first Emacs 22 pretest tarball, it would be nice if
>> people could take a look and make sure there are no problems building
>> from, before we think about making any pretest announcement.
>
> On this system:
>
> Linux fencepost 2.6.12-fencepost #1 SMP Wed Jul 19 10:55:11 EDT
> 2006 i686 GNU/Linux
>
> I cannot build the pretest: it fails while linking temacs.
>
> Interestingly, the same machine builds the CVS version just fine (and
> has been doing that for a very long time).
That's pretty strange. If you generate a tarball from CVS yourself,
using emacs/make-dist, does that tarball fail to build?
Try also deleting configure and doing `make bootstrap' to generate a
new configure file (in case there's some bug in the version of
autoconf I'm using). Does it work in that case?
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
[not found] ` <cyd@stupidchicken.com>
@ 2006-10-28 15:08 ` Alfred M. Szmidt
2006-10-28 20:52 ` Pretest Chong Yidong
0 siblings, 1 reply; 172+ messages in thread
From: Alfred M. Szmidt @ 2006-10-28 15:08 UTC (permalink / raw)
Cc: emacs-devel
It doesn't build on OpenBSD:
| OpenBSD 3.9 (GENERIC) #617: Thu Mar 2 02:26:48 MST 2006
The strange thing is that tiff is found correctly, and that all goes
well up to the point of linking:
| ...
| checking for TIFFGetVersion in -ltiff... yes
| ...
Here is the relevant part of the build log:
gcc -nostartfiles `echo -R/usr/X11R6/lib | sed -e 's/-R/-Wl,-rpath,/'` -Z -Wl,-znocombreloc -L/usr/X11R6/lib -o temacs pre-crt0.o /usr/lib/crt0.o /usr/lib/crtbegin.o dispnew.o frame.o scroll.o xdisp.o xmenu.o window.o charset.o coding.o category.o ccl.o cm.o term.o xfaces.o xterm.o xfns.o xselect.o xrdb.o fontset.o xsmfns.o fringe.o image.o emacs.o keyboard.o macros.o keymap.o sysdep.o buffer.o filelock.o insdel.o marker.o minibuf.o fileio.o dired.o filemode.o cmds.o casetab.o casefiddle.o indent.o search.o regex.o undo.o alloc.o data.o doc.o editfns.o callint.o eval.o floatfns.o fns.o print.o lread.o abbrev.o syntax.o unexelf.o bytecode.o process.o callproc.o region-cache.o sound.o atimer.o doprnt.o strftime.o intervals.o textprop.o composite.o md5.o terminfo.o lastfile.o gmalloc.o ralloc.o vm-limit.o widget.o ../lwlib/liblw.a -L/usr/X11R6/lib -lXaw -lXmu -lXt -lSM -lICE -lXext
-ltiff -ljpeg -lpng -lz -lm -lungif -lXpm -lX11 -lossaudio -lncurses -lm -lgcc -lc -lgcc /usr/lib/crtend.o
/usr/bin/ld: cannot find -ltiff
collect2: ld returned 1 exit status
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-10-28 13:30 ` Pretest Benjamin Riefenstahl
@ 2006-10-28 15:25 ` Chong Yidong
0 siblings, 0 replies; 172+ messages in thread
From: Chong Yidong @ 2006-10-28 15:25 UTC (permalink / raw)
Cc: emacs-devel
Benjamin Riefenstahl <b.riefenstahl@turtle-trading.net> writes:
> Hi,
>
>
> Chong Yidong writes:
>> I've bumped the version number to 22.0.90 and rolled a pretest
>> tarball.
>
> Cool.
>
>> it would be nice if people could take a look and make sure there are
>> no problems building from,
>
> Building on Mac OS X (10.3), "make" fails with (last lines only):
>
> Writing LC_UNIXTHREAD command
> 26524 unused bytes follow Mach-O header
> 1099612 pure bytes used
> ./emacs -q -batch -f list-load-path-shadows
> make[1]: *** No rule to make target `/Users/benny/Projects/emacs-22.0.90/src/../mac/Emacs.app/Contents/Resources/Emacs.icns', needed by `macosx-bundle'. Stop.
> make: *** [src] Error 2
>
> It seems that mac/Emacs.app/Contents/Resources/Emacs.icns is missing.
>
> After I copy the file from a CVS checkout, "make" proceeds and the
> result of "make install" seems to work fine.
Yamamoto Mitsuharu has fixed this bug, and the files required to
compile on Macs should be included in the next pretest tarball.
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-10-28 13:38 ` Pretest Eli Zaretskii
@ 2006-10-28 15:53 ` Chong Yidong
2006-10-28 19:05 ` Pretest Eli Zaretskii
0 siblings, 1 reply; 172+ messages in thread
From: Chong Yidong @ 2006-10-28 15:53 UTC (permalink / raw)
Cc: emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
> . The first line of some of the Info file cites its full absolute
> file name on your machine, like this:
>
> This is /home/cyd/emacs/lispintro/../info/eintr, produced by makeinfo
> version 4.8 from /home/cyd/emacs/lispintro/emacs-lisp-intro.texi.
>
> I don't know how this happened, especially since some of the files
> have the correct text:
>
> This is ../info/emacs, produced by makeinfo version 4.8 from emacs.texi.
Good catch. This seems to be due to a difference in the man and
lispref/lispintro Makefiles. The way man does it is
INFO_TARGETS = ../info/emacs ../info/ccmode ....[etc]
info: $(top_srcdir)/info $(INFO_TARGETS)
../info/emacs: ${EMACSSOURCES}
cd $(srcdir); $(MAKEINFO) emacs.texi
whereas lispref does it like this:
srcs = $(srcdir)/abbrevs.texi ....[etc]
info: $(infodir)/elisp
$(infodir)/elisp: $(srcs)
$(MAKEINFO) -I. -I$(srcdir) $(srcdir)/elisp.texi -o $(infodir)/elisp
By analogy, this last line should be replaced by
cd $(srcdir); $(MAKEINFO) elisp.texi
> . The file info/emacs-xtra was produced incorrectly: it includes all
> the stuff that should only be in the printed version, and is
> therefore conditioned by @iftex. I have no other clue to this
> mystery except that the fact that it was somehow produced by a
> different version of Makeinfo:
>
> This is ../info/emacs-xtra, produced by makeinfo version 4.7 from
> emacs-xtra.texi.
>
> (A few other files are built by makeinfo 4.7 as well.)
There were probably stale info files in my CVS info directory. I just
cleaned it out; this problem should go away in the next pretest
tarball.
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-10-27 17:59 Pretest Chong Yidong
` (13 preceding siblings ...)
[not found] ` <cyd@stupidchicken.com>
@ 2006-10-28 18:13 ` Richard Stallman
2006-10-28 19:02 ` Pretest Eli Zaretskii
2006-11-03 15:39 ` Pretest Drew Adams
2006-10-30 20:04 ` Pretest Paul Jarc
` (2 subsequent siblings)
17 siblings, 2 replies; 172+ messages in thread
From: Richard Stallman @ 2006-10-28 18:13 UTC (permalink / raw)
Cc: emacs-devel
The question is, who do we announce the pretest to?
I have a list of pretesters that I send the announcement to. I keep
it in sync with emacs-pretesters, but I don't send the announcement
_to_ that mailing list, because that would tend to lead everyone to
mail all their statements of success or failure to the list as well.
People should use that list only when they have a specific reason to
do so.
I have not updated the list for a few years. I should do it now,
but we can announce the first pretest before updating it.
If not, I think we should just
make a public announcement about the availability of the pretest
tarball on the Gnu Emacs webpage.
We can do that too.
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-10-28 18:13 ` Pretest Richard Stallman
@ 2006-10-28 19:02 ` Eli Zaretskii
2006-10-29 18:49 ` Pretest Richard Stallman
2006-11-03 15:39 ` Pretest Drew Adams
1 sibling, 1 reply; 172+ messages in thread
From: Eli Zaretskii @ 2006-10-28 19:02 UTC (permalink / raw)
Cc: cyd, emacs-devel
> From: Richard Stallman <rms@gnu.org>
> Date: Sat, 28 Oct 2006 14:13:36 -0400
> Cc: emacs-devel@gnu.org
>
> I have a list of pretesters that I send the announcement to. I keep
> it in sync with emacs-pretesters, but I don't send the announcement
> _to_ that mailing list, because that would tend to lead everyone to
> mail all their statements of success or failure to the list as well.
Won't `Reply-to' solve this more conveniently?
> People should use that list only when they have a specific reason to
> do so.
The usual reasons were, IIRC, to inform the pretesters about known
problems and their solutions/workarounds.
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-10-28 15:53 ` Pretest Chong Yidong
@ 2006-10-28 19:05 ` Eli Zaretskii
2006-10-29 21:36 ` Pretest Chong Yidong
0 siblings, 1 reply; 172+ messages in thread
From: Eli Zaretskii @ 2006-10-28 19:05 UTC (permalink / raw)
Cc: emacs-devel
> Cc: emacs-devel@gnu.org
> From: Chong Yidong <cyd@stupidchicken.com>
> Date: Sat, 28 Oct 2006 11:53:29 -0400
>
> Good catch. This seems to be due to a difference in the man and
> lispref/lispintro Makefiles. The way man does it is
>
> INFO_TARGETS = ../info/emacs ../info/ccmode ....[etc]
>
> info: $(top_srcdir)/info $(INFO_TARGETS)
>
> ../info/emacs: ${EMACSSOURCES}
> cd $(srcdir); $(MAKEINFO) emacs.texi
>
> whereas lispref does it like this:
>
> srcs = $(srcdir)/abbrevs.texi ....[etc]
>
> info: $(infodir)/elisp
>
> $(infodir)/elisp: $(srcs)
> $(MAKEINFO) -I. -I$(srcdir) $(srcdir)/elisp.texi -o $(infodir)/elisp
>
> By analogy, this last line should be replaced by
>
> cd $(srcdir); $(MAKEINFO) elisp.texi
I have no objections to such a change, but note that $(MAKEINFO)
doesn't include the -I switches in lispref/Makefile.in, so if we want
to make such a change, we should probably add them to the macro.
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-10-28 15:01 ` Pretest Chong Yidong
@ 2006-10-28 19:28 ` Eli Zaretskii
2006-10-28 20:47 ` Pretest Chong Yidong
0 siblings, 1 reply; 172+ messages in thread
From: Eli Zaretskii @ 2006-10-28 19:28 UTC (permalink / raw)
Cc: emacs-devel
> Cc: emacs-devel@gnu.org
> From: Chong Yidong <cyd@stupidchicken.com>
> Date: Sat, 28 Oct 2006 11:01:08 -0400
> >
> > I cannot build the pretest: it fails while linking temacs.
> >
> > Interestingly, the same machine builds the CVS version just fine (and
> > has been doing that for a very long time).
>
>
> That's pretty strange. If you generate a tarball from CVS yourself,
> using emacs/make-dist, does that tarball fail to build?
>
> Try also deleting configure and doing `make bootstrap' to generate a
> new configure file (in case there's some bug in the version of
> autoconf I'm using). Does it work in that case?
The latter method worked. The version of Autoconf installed on
fencepost is 2.59. I see that the one you used also identifies itself
as 2.59, but they produce a different configure script(!); the diffs
are attached below. Do you see anything in the diffs that could
explain the failure? I don't. (The file src/config.in produced by
autoheader is identical to what you included in the tarball, so
config.h is not the culprit. The produced src/Makefile files are also
identical.)
I'd still like to understand what failed `ld'.
--- bad/emacs-22.0.90/configure 2006-10-27 11:17:48.000000000 -0400
+++ good/emacs-22.0.90/configure 2006-10-28 15:06:50.000000000 -0400
@@ -988,7 +988,7 @@
else
echo "$as_me: WARNING: no configuration information is in $ac_dir" >&2
fi
- cd "$ac_popdir"
+ cd $ac_popdir
done
fi
@@ -3283,7 +3283,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -3341,7 +3342,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -3457,7 +3459,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -3511,7 +3514,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -3556,7 +3560,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -3600,7 +3605,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -3988,7 +3994,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -4616,7 +4623,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -4842,7 +4850,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -4871,7 +4880,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -4941,7 +4951,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -4993,7 +5004,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -5064,7 +5076,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -5116,7 +5129,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -5190,7 +5204,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -5360,7 +5375,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -5429,7 +5445,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -5583,7 +5600,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -5790,7 +5808,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -5932,7 +5951,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -6051,7 +6071,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -6216,7 +6237,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -6279,7 +6301,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -6352,7 +6375,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -6438,7 +6462,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -6511,7 +6536,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -6581,7 +6607,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -6640,7 +6667,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -6709,7 +6737,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -6770,7 +6799,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -6836,7 +6866,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -6982,7 +7013,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -7046,7 +7078,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -7111,7 +7144,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -7157,7 +7191,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -7231,7 +7266,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -7296,7 +7332,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -7340,7 +7377,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -7411,7 +7449,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -7461,7 +7500,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -7532,7 +7572,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -7582,7 +7623,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -7653,7 +7695,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -7703,7 +7746,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -7774,7 +7818,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -7824,7 +7869,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -7895,7 +7941,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -7945,7 +7992,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -8032,7 +8080,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -8138,7 +8187,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -8198,7 +8248,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -8322,7 +8373,6 @@
echo "$as_me:$LINENO: checking for X" >&5
echo $ECHO_N "checking for X... $ECHO_C" >&6
-ac_path_x_has_been_run=yes
# Check whether --with-x or --without-x was given.
if test "${with_x+set}" = set; then
@@ -8415,7 +8465,7 @@
/usr/openwin/share/include'
if test "$ac_x_includes" = no; then
- # Guess where to find include files, by looking for a specified header file.
+ # Guess where to find include files, by looking for Intrinsic.h.
# First, try using that file with no special directory specified.
cat >conftest.$ac_ext <<_ACEOF
/* confdefs.h. */
@@ -8423,7 +8473,7 @@
cat confdefs.h >>conftest.$ac_ext
cat >>conftest.$ac_ext <<_ACEOF
/* end confdefs.h. */
-#include <X11/Xlib.h>
+#include <X11/Intrinsic.h>
_ACEOF
if { (eval echo "$as_me:$LINENO: \"$ac_cpp conftest.$ac_ext\"") >&5
(eval $ac_cpp conftest.$ac_ext) 2>conftest.er1
@@ -8450,7 +8500,7 @@
sed 's/^/| /' conftest.$ac_ext >&5
for ac_dir in $ac_x_header_dirs; do
- if test -r "$ac_dir/X11/Xlib.h"; then
+ if test -r "$ac_dir/X11/Intrinsic.h"; then
ac_x_includes=$ac_dir
break
fi
@@ -8464,18 +8514,18 @@
# See if we find them without any special options.
# Don't add to $LIBS permanently.
ac_save_LIBS=$LIBS
- LIBS="-lX11 $LIBS"
+ LIBS="-lXt $LIBS"
cat >conftest.$ac_ext <<_ACEOF
/* confdefs.h. */
_ACEOF
cat confdefs.h >>conftest.$ac_ext
cat >>conftest.$ac_ext <<_ACEOF
/* end confdefs.h. */
-#include <X11/Xlib.h>
+#include <X11/Intrinsic.h>
int
main ()
{
-XrmInitialize ()
+XtMalloc (0)
;
return 0;
}
@@ -8489,7 +8539,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -8513,7 +8564,7 @@
do
# Don't even attempt the hair of trying to link an X program!
for ac_extension in a so sl; do
- if test -r $ac_dir/libX11.$ac_extension; then
+ if test -r $ac_dir/libXt.$ac_extension; then
ac_x_libraries=$ac_dir
break 2
fi
@@ -8549,12 +8600,8 @@
# Update the cache value to reflect the command line values.
ac_cv_have_x="have_x=yes \
ac_x_includes=$x_includes ac_x_libraries=$x_libraries"
- # It might be that x_includes is empty (headers are found in the
- # standard search path. Then output the corresponding message
- ac_out_x_includes=$x_includes
- test "x$x_includes" = x && ac_out_x_includes="in standard search path"
- echo "$as_me:$LINENO: result: libraries $x_libraries, headers $ac_out_x_includes" >&5
-echo "${ECHO_T}libraries $x_libraries, headers $ac_out_x_includes" >&6
+ echo "$as_me:$LINENO: result: libraries $x_libraries, headers $x_includes" >&5
+echo "${ECHO_T}libraries $x_libraries, headers $x_includes" >&6
fi
if test "$no_x" = yes; then
@@ -8643,7 +8690,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -8879,7 +8927,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -8974,7 +9023,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -9033,7 +9083,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -9117,7 +9168,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -9301,7 +9353,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -9553,7 +9606,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -9620,7 +9674,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -9689,7 +9744,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -9774,7 +9830,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -9851,7 +9908,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -9905,7 +9963,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -9974,7 +10033,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -10078,7 +10138,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -10145,7 +10206,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -10215,7 +10277,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -10456,7 +10519,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -10565,7 +10629,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -10668,7 +10733,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -10746,7 +10812,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -10900,7 +10967,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -10974,7 +11042,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -11046,7 +11115,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -11128,7 +11198,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -11207,7 +11278,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -11278,7 +11350,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -11347,7 +11420,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -11420,7 +11494,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -11543,7 +11618,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -11645,7 +11721,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -11725,7 +11802,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -11793,7 +11871,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -11938,7 +12017,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -12047,7 +12127,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -12192,7 +12273,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -12299,7 +12381,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -12453,7 +12536,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -12528,7 +12612,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -12676,7 +12761,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -12753,7 +12839,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -12900,7 +12987,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -12973,7 +13061,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -13174,7 +13263,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -13247,7 +13337,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -13392,7 +13483,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -13468,7 +13560,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -13531,7 +13624,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -13612,7 +13706,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -13753,7 +13848,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -13898,7 +13994,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -13974,7 +14071,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -14047,7 +14145,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -14202,7 +14301,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -14268,7 +14368,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -14528,7 +14629,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -14595,7 +14697,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -14747,7 +14850,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -14931,7 +15035,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -15258,7 +15363,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -15359,7 +15465,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -15432,7 +15539,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -15511,7 +15619,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -15580,7 +15689,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -15648,7 +15758,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -15722,7 +15833,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -15826,7 +15938,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -15901,7 +16014,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -16053,7 +16167,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -16121,7 +16236,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -16298,7 +16414,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -16374,7 +16491,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -16528,7 +16646,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -16679,7 +16798,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -16830,7 +16950,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -16972,7 +17093,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -17016,7 +17138,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -17162,7 +17285,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -17206,7 +17330,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -17271,7 +17396,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -17361,7 +17487,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -17548,7 +17675,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -17618,7 +17746,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -17687,7 +17816,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -17819,7 +17949,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -17921,7 +18052,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -17990,7 +18122,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -18097,7 +18230,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -18200,7 +18334,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -18276,7 +18411,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -18380,7 +18516,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -18472,7 +18609,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -18537,7 +18675,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -18603,7 +18742,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -18713,7 +18853,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -18778,7 +18919,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -18858,7 +19000,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -18931,7 +19074,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -19004,7 +19148,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -19077,7 +19222,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -19151,7 +19297,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -19223,7 +19370,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -19298,7 +19446,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -19370,7 +19519,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -19443,7 +19593,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -19593,7 +19744,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -19739,7 +19891,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -19885,7 +20038,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -20042,7 +20196,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -20188,7 +20343,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -20334,7 +20490,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -20492,7 +20649,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -20650,7 +20808,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -20839,7 +20998,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -20912,7 +21072,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -20980,7 +21141,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -21026,7 +21188,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -21100,7 +21263,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -21164,7 +21328,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -21302,7 +21467,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -21363,7 +21529,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -21508,7 +21675,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -21664,7 +21832,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -21835,7 +22004,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -21903,7 +22073,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -22088,7 +22259,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -22130,24 +22302,18 @@
ac_cv_func_fork_works=cross
else
cat >conftest.$ac_ext <<_ACEOF
-/* confdefs.h. */
-_ACEOF
-cat confdefs.h >>conftest.$ac_ext
-cat >>conftest.$ac_ext <<_ACEOF
-/* end confdefs.h. */
-$ac_includes_default
-int
-main ()
-{
-
- /* By Ruediger Kuhlmann. */
- if (fork() < 0)
- exit (1);
- exit (0);
-
- ;
- return 0;
-}
+/* By Ruediger Kuhlmann. */
+ #include <sys/types.h>
+ #if HAVE_UNISTD_H
+ # include <unistd.h>
+ #endif
+ /* Some systems only have a dummy stub for fork() */
+ int main ()
+ {
+ if (fork() < 0)
+ exit (1);
+ exit (0);
+ }
_ACEOF
rm -f conftest$ac_exeext
if { (eval echo "$as_me:$LINENO: \"$ac_link\"") >&5
@@ -22387,7 +22553,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -22452,7 +22619,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -22515,7 +22683,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -22581,7 +22750,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -22622,7 +22792,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -22689,7 +22860,8 @@
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -23809,6 +23981,11 @@
*) ac_INSTALL=$ac_top_builddir$INSTALL ;;
esac
+ if test x"$ac_file" != x-; then
+ { echo "$as_me:$LINENO: creating $ac_file" >&5
+echo "$as_me: creating $ac_file" >&6;}
+ rm -f "$ac_file"
+ fi
# Let's still pretend it is `configure' which instantiates (i.e., don't
# use $as_me), people would be surprised to read:
# /* config.h. Generated by config.status. */
@@ -23847,12 +24024,6 @@
fi;;
esac
done` || { (exit 1); exit 1; }
-
- if test x"$ac_file" != x-; then
- { echo "$as_me:$LINENO: creating $ac_file" >&5
-echo "$as_me: creating $ac_file" >&6;}
- rm -f "$ac_file"
- fi
_ACEOF
cat >>$CONFIG_STATUS <<_ACEOF
sed "$ac_vpsub
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
@ 2006-10-28 20:33 Mikko Huhtala
0 siblings, 0 replies; 172+ messages in thread
From: Mikko Huhtala @ 2006-10-28 20:33 UTC (permalink / raw)
Chong Yidong schrieb:
> ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-22.0.90.tar.gz
>
> Since this is the first Emacs 22 pretest tarball, it would be nice
> if people could take a look and make sure there are no problems
> building from, before we think about making any pretest
> announcement.
Seems to build and work just fine. I'm using gtk2 on the following system:
Fedora Core release 6 (Zod)
Linux 2.6.18-1.2798.fc6 #1 SMP Mon Oct 16 14:37:32 EDT 2006 i686 i686 i386 GNU/Linux
glibc-2.5-3
gcc-4.1.1-30
gtk2-2.10.4-4.fc6
xorg-x11-server-Xorg-1.1.1-47.fc6
I'm posting this from Emacs 22.0.90 and I used VM 7.19 to read mail,
which seems to work without problems.
Mikko
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-10-28 19:28 ` Pretest Eli Zaretskii
@ 2006-10-28 20:47 ` Chong Yidong
2006-10-29 7:43 ` Pretest Eli Zaretskii
0 siblings, 1 reply; 172+ messages in thread
From: Chong Yidong @ 2006-10-28 20:47 UTC (permalink / raw)
Cc: emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> Try also deleting configure and doing `make bootstrap' to generate a
>> new configure file (in case there's some bug in the version of
>> autoconf I'm using). Does it work in that case?
>
> The latter method worked. The version of Autoconf installed on
> fencepost is 2.59. I see that the one you used also identifies itself
> as 2.59, but they produce a different configure script(!)
Maybe it's due to some Debian-specific patch to autoconf (I'm using
the version shipped with Ubuntu Dapper, version 2.59a-7). We could
revert configure to the last version used, and stick with the
configure script for the rest of the pretest.
> Do you see anything in the diffs that could explain the failure? I
> don't. (The file src/config.in produced by autoheader is identical
> to what you included in the tarball, so config.h is not the culprit.
> The produced src/Makefile files are also identical.)
>
> I'd still like to understand what failed `ld'.
I think the easiest thing to do is to apply the hunks of the diff
until you find which part causes compilation to fail for you. It
shouldn't take that long with a binary-search.
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-10-28 15:08 ` Pretest Alfred M. Szmidt
@ 2006-10-28 20:52 ` Chong Yidong
2006-10-28 21:11 ` Pretest Alfred M. Szmidt
0 siblings, 1 reply; 172+ messages in thread
From: Chong Yidong @ 2006-10-28 20:52 UTC (permalink / raw)
Cc: emacs-devel
"Alfred M. Szmidt" <ams@gnu.org> writes:
> It doesn't build on OpenBSD:
Is this x86-64 OpenBSD? A patch was recently sent to this list that
fixes compilation on that platform, but it seems not to have been
checked in by the time I rolled the tarball. Someone should check it
into CVS; then it'll show up in the next tarball.
> | OpenBSD 3.9 (GENERIC) #617: Thu Mar 2 02:26:48 MST 2006
>
> The strange thing is that tiff is found correctly, and that all goes
> well up to the point of linking:
>
> | ...
> | checking for TIFFGetVersion in -ltiff... yes
> | ...
>
> Here is the relevant part of the build log:
>
> gcc -nostartfiles `echo -R/usr/X11R6/lib | sed -e 's/-R/-Wl,-rpath,/'` -Z -Wl,-znocombreloc -L/usr/X11R6/lib -o temacs pre-crt0.o /usr/lib/crt0.o /usr/lib/crtbegin.o dispnew.o frame.o scroll.o xdisp.o xmenu.o window.o charset.o coding.o category.o ccl.o cm.o term.o xfaces.o xterm.o xfns.o xselect.o xrdb.o fontset.o xsmfns.o fringe.o image.o emacs.o keyboard.o macros.o keymap.o sysdep.o buffer.o filelock.o insdel.o marker.o minibuf.o fileio.o dired.o filemode.o cmds.o casetab.o casefiddle.o indent.o search.o regex.o undo.o alloc.o data.o doc.o editfns.o callint.o eval.o floatfns.o fns.o print.o lread.o abbrev.o syntax.o unexelf.o bytecode.o process.o callproc.o region-cache.o sound.o atimer.o doprnt.o strftime.o intervals.o textprop.o composite.o md5.o terminfo.o lastfile.o gmalloc.o ralloc.o vm-limit.o widget.o ../lwlib/liblw.a -L/usr/X11R6/lib -lXaw -lXmu -lXt -lSM -lICE -lXe
xt -ltiff -ljpeg -lpng -lz -lm -lungif -lXpm -lX11 -lossaudio -lncurses -lm -lgcc -lc -!
lgc
> c /usr/lib/crtend.o
> /usr/bin/ld: cannot find -ltiff
> collect2: ld returned 1 exit status
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-10-28 20:52 ` Pretest Chong Yidong
@ 2006-10-28 21:11 ` Alfred M. Szmidt
2006-10-28 22:09 ` Pretest Chong Yidong
0 siblings, 1 reply; 172+ messages in thread
From: Alfred M. Szmidt @ 2006-10-28 21:11 UTC (permalink / raw)
Cc: emacs-devel
> It doesn't build on OpenBSD:
Is this x86-64 OpenBSD?
No, this is plain 8x86 OpenBSD.
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-10-28 13:14 ` Pretest Eli Zaretskii
@ 2006-10-28 21:47 ` Jason Rumney
2006-10-29 4:30 ` Pretest Eli Zaretskii
0 siblings, 1 reply; 172+ messages in thread
From: Jason Rumney @ 2006-10-28 21:47 UTC (permalink / raw)
Cc: cyd, emacs-devel
Eli Zaretskii wrote:
> It's a real bug, it happens the first time a source tree is compiled.
>
> Please try the patch below. I will check it in if there are no
> objections.
>
This fixes the problem for me. But if temacs.exe is not needed to
produce the DOC file, why do we depend on it in the first place?
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-10-28 21:11 ` Pretest Alfred M. Szmidt
@ 2006-10-28 22:09 ` Chong Yidong
2006-10-28 22:30 ` Pretest Alfred M. Szmidt
0 siblings, 1 reply; 172+ messages in thread
From: Chong Yidong @ 2006-10-28 22:09 UTC (permalink / raw)
Cc: emacs-devel
"Alfred M. Szmidt" <ams@gnu.org> writes:
> > It doesn't build on OpenBSD:
>
> Is this x86-64 OpenBSD?
>
> No, this is plain 8x86 OpenBSD.
Could you try regenerating configure by running autoconf in the
emacs-22.0.90, then running ./configure && make? Does compilation
work then?
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-10-28 22:09 ` Pretest Chong Yidong
@ 2006-10-28 22:30 ` Alfred M. Szmidt
2006-10-29 23:40 ` Pretest Chong Yidong
0 siblings, 1 reply; 172+ messages in thread
From: Alfred M. Szmidt @ 2006-10-28 22:30 UTC (permalink / raw)
Cc: emacs-devel
> > It doesn't build on OpenBSD:
>
> Is this x86-64 OpenBSD?
>
> No, this is plain 8x86 OpenBSD.
Could you try regenerating configure by running autoconf in the
emacs-22.0.90, then running ./configure && make? Does compilation
work then?
I tried this, it didn't work. The reason from the looks is that the
library search path is not propagated correctly. This is what
config.log contains (tiff is installed in /usr/local):
| configure:12641: checking for TIFFGetVersion in -ltiff
| configure:12671: gcc -o conftest -I/usr/X11R6/include -g -O2 -I/usr/X11R6/include -I/usr/X11R6/include -I/usr/pkg/include -I/usr/local/include -L/usr/pkg/lib -L/usr/local/lib -Wl,-znocombreloc -L/usr/X11R6/lib conftest.c -ltiff -ljpeg -lz -lm -lXext -lXmu -lXt -lSM -lICE -lX11 >&5 -Z
But at linking, none of the search paths are passed, and hence the
missing library error.
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-10-28 21:47 ` Pretest Jason Rumney
@ 2006-10-29 4:30 ` Eli Zaretskii
2006-10-29 11:17 ` Pretest Jason Rumney
0 siblings, 1 reply; 172+ messages in thread
From: Eli Zaretskii @ 2006-10-29 4:30 UTC (permalink / raw)
Cc: cyd, emacs-devel
> Date: Sat, 28 Oct 2006 22:47:11 +0100
> From: Jason Rumney <jasonr@gnu.org>
> Cc: cyd@stupidchicken.com, emacs-devel@gnu.org
>
> This fixes the problem for me.
Do you have some sh.exe on your PATH, or did you use CMD? I think my
patch would not work with CMD, due to forward slashes in the
redirection. I think I'd replace that with some cp command.
> But if temacs.exe is not needed to produce the DOC file, why do we
> depend on it in the first place?
So that, whenever temacs.exe is rebuilt (meaning that some C file has
changed), DOC is regenerated by "make install".
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-10-28 20:47 ` Pretest Chong Yidong
@ 2006-10-29 7:43 ` Eli Zaretskii
2006-10-29 22:11 ` Pretest Chong Yidong
2006-10-30 13:33 ` Pretest Richard Stallman
0 siblings, 2 replies; 172+ messages in thread
From: Eli Zaretskii @ 2006-10-29 7:43 UTC (permalink / raw)
Cc: emacs-devel
> From: Chong Yidong <cyd@stupidchicken.com>
> Date: Sat, 28 Oct 2006 16:47:07 -0400
> Cc: emacs-devel@gnu.org
>
> I'm using the version shipped with Ubuntu Dapper, version 2.59a-7
This version sounds like it's some kind of development snapshot. Can
you try to find out? Maybe we shouldn't be using this version.
> We could revert configure to the last version used, and stick with
> the configure script for the rest of the pretest.
That's not a good solution, IMO, since some bugs reported during the
pretest might require to regenerate the script.
> > I'd still like to understand what failed `ld'.
>
> I think the easiest thing to do is to apply the hunks of the diff
> until you find which part causes compilation to fail for you. It
> shouldn't take that long with a binary-search.
I don't know when I'll have time to do that; fencepost.gnu.org is not
my main machine. Even if I do find the portion of the diffs that
causes the problem, then what? We don't have a version of Autoconf
that would have the effect of applying only part of the diffs, so once
again we will be in a position where regenerating the configure script
would be difficult of impossible.
And on top of that, I still have trouble understanding how any change
in the configure script _alone_ could have anything to do with this.
Unless I'm missing something, there are only 2 ways Autoconf can
affect the temacs build: either through config.in/config.h, or through
src/Makefile. These are the only two things I know off that affect
compilation and linking of the C sources.
However, in this case, config.in and config.h are identical to the
ones you included in the tarball, and so is src/Makefile.in. Am I
missing something?
So I'm still thinking the `ld' failure was some real problem, and the
changes in the configure script are only indirectly related to it. If
someone knows how to investigate the `ld' failure (short of rebuilding
Binutils with debug info and running `ld' under a debugger), I'd
appreciate any ideas.
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-10-29 4:30 ` Pretest Eli Zaretskii
@ 2006-10-29 11:17 ` Jason Rumney
2006-10-29 11:47 ` Pretest Eli Zaretskii
2006-11-04 12:15 ` Pretest Eli Zaretskii
0 siblings, 2 replies; 172+ messages in thread
From: Jason Rumney @ 2006-10-29 11:17 UTC (permalink / raw)
Cc: cyd, emacs-devel
Eli Zaretskii wrote:
> Do you have some sh.exe on your PATH, or did you use CMD? I think my
> patch would not work with CMD, due to forward slashes in the
> redirection. I think I'd replace that with some cp command.
>
There is no sh.exe in my path, so I think it would have used cmd.exe.
Perhaps mingw32-make converted the path before passing to cmd.exe? But
cp would be safer.
>> But if temacs.exe is not needed to produce the DOC file, why do we
>> depend on it in the first place?
>>
>
> So that, whenever temacs.exe is rebuilt (meaning that some C file has
> changed), DOC is regenerated by "make install".
>
Then wouldn't it be better to build DOC after temacs? Otherwise we lag
behind by one build, since temacs does not get modified until after the
DOC file is generated.
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-10-29 11:17 ` Pretest Jason Rumney
@ 2006-10-29 11:47 ` Eli Zaretskii
2006-10-30 13:33 ` Pretest Richard Stallman
2006-11-04 12:15 ` Pretest Eli Zaretskii
1 sibling, 1 reply; 172+ messages in thread
From: Eli Zaretskii @ 2006-10-29 11:47 UTC (permalink / raw)
Cc: cyd, emacs-devel
> Date: Sun, 29 Oct 2006 11:17:05 +0000
> From: Jason Rumney <jasonr@gnu.org>
> Cc: cyd@stupidchicken.com, emacs-devel@gnu.org
> >
> > So that, whenever temacs.exe is rebuilt (meaning that some C file has
> > changed), DOC is regenerated by "make install".
> >
> Then wouldn't it be better to build DOC after temacs?
Yes (that's what the Unix build does), but I'm reluctant to do that
now, since it would be a major change in the Windows build procedure.
> Otherwise we lag behind by one build, since temacs does not get
> modified until after the DOC file is generated.
Why does it have to be modified? What kind of information about DOC
is recorded in temacs?
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-10-28 11:17 ` Pretest Eli Zaretskii
@ 2006-10-29 18:45 ` Richard Stallman
2006-10-29 20:20 ` Pretest Eli Zaretskii
0 siblings, 1 reply; 172+ messages in thread
From: Richard Stallman @ 2006-10-29 18:45 UTC (permalink / raw)
Cc: cyd, emacs-devel, storm
It makes no sense to post a delta for the first pretest,
because that would be almost as big as the sources.
However, we should post deltas for subsequent pretests
from the first pretest.
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-10-28 19:02 ` Pretest Eli Zaretskii
@ 2006-10-29 18:49 ` Richard Stallman
2006-10-29 20:22 ` Pretest Eli Zaretskii
0 siblings, 1 reply; 172+ messages in thread
From: Richard Stallman @ 2006-10-29 18:49 UTC (permalink / raw)
Cc: cyd, emacs-devel
> I have a list of pretesters that I send the announcement to. I keep
> it in sync with emacs-pretesters, but I don't send the announcement
> _to_ that mailing list, because that would tend to lead everyone to
> mail all their statements of success or failure to the list as well.
Won't `Reply-to' solve this more conveniently?
I am not sure. What would we put in the Reply-to field?
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-10-29 18:45 ` Pretest Richard Stallman
@ 2006-10-29 20:20 ` Eli Zaretskii
0 siblings, 0 replies; 172+ messages in thread
From: Eli Zaretskii @ 2006-10-29 20:20 UTC (permalink / raw)
Cc: cyd, emacs-devel, storm
> From: Richard Stallman <rms@gnu.org>
> CC: storm@cua.dk, cyd@stupidchicken.com, emacs-devel@gnu.org
> Date: Sun, 29 Oct 2006 13:45:56 -0500
>
> It makes no sense to post a delta for the first pretest,
> because that would be almost as big as the sources.
> However, we should post deltas for subsequent pretests
> from the first pretest.
I agree. I never meant to suggest that we make an xdelta for the
first pretest, sorry if that wasn't clear.
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-10-29 18:49 ` Pretest Richard Stallman
@ 2006-10-29 20:22 ` Eli Zaretskii
2006-10-30 19:16 ` Pretest Richard Stallman
0 siblings, 1 reply; 172+ messages in thread
From: Eli Zaretskii @ 2006-10-29 20:22 UTC (permalink / raw)
Cc: cyd, emacs-devel
> From: Richard Stallman <rms@gnu.org>
> CC: cyd@stupidchicken.com, emacs-devel@gnu.org
> Date: Sun, 29 Oct 2006 13:49:43 -0500
>
> > I have a list of pretesters that I send the announcement to. I keep
> > it in sync with emacs-pretesters, but I don't send the announcement
> > _to_ that mailing list, because that would tend to lead everyone to
> > mail all their statements of success or failure to the list as well.
>
> Won't `Reply-to' solve this more conveniently?
>
> I am not sure. What would we put in the Reply-to field?
I think emacs-pretest-bug@gnu.org is the right address to put there.
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-10-28 19:05 ` Pretest Eli Zaretskii
@ 2006-10-29 21:36 ` Chong Yidong
2006-10-30 4:25 ` Pretest Eli Zaretskii
0 siblings, 1 reply; 172+ messages in thread
From: Chong Yidong @ 2006-10-29 21:36 UTC (permalink / raw)
Cc: emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> By analogy, this last line should be replaced by
>>
>> cd $(srcdir); $(MAKEINFO) elisp.texi
>
> I have no objections to such a change, but note that $(MAKEINFO)
> doesn't include the -I switches in lispref/Makefile.in, so if we want
> to make such a change, we should probably add them to the macro.
I've checked such a change.
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-10-29 7:43 ` Pretest Eli Zaretskii
@ 2006-10-29 22:11 ` Chong Yidong
2006-10-30 21:50 ` Pretest Eli Zaretskii
2006-10-30 13:33 ` Pretest Richard Stallman
1 sibling, 1 reply; 172+ messages in thread
From: Chong Yidong @ 2006-10-29 22:11 UTC (permalink / raw)
Cc: emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> I'm using the version shipped with Ubuntu Dapper, version 2.59a-7
>
> This version sounds like it's some kind of development snapshot. Can
> you try to find out? Maybe we shouldn't be using this version.
You may be right. I downgraded autoconf to version 2.59-5, and
regenerated configure in CVS. Can you try with this version and see
if compilation works?
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-10-28 22:30 ` Pretest Alfred M. Szmidt
@ 2006-10-29 23:40 ` Chong Yidong
2006-10-30 0:33 ` Pretest Alfred M. Szmidt
0 siblings, 1 reply; 172+ messages in thread
From: Chong Yidong @ 2006-10-29 23:40 UTC (permalink / raw)
Cc: emacs-devel
"Alfred M. Szmidt" <ams@gnu.org> writes:
> The reason from the looks is that the library search path is not
> propagated correctly. This is what config.log contains (tiff is
> installed in /usr/local):
>
> But at linking, none of the search paths are passed, and hence the
> missing library error.
I'm guessing you're passing an LDFLAGS envvar to configure. Seems
like LDFLAGS isn't getting passed to X11_LDFLAGS. Try applying the
following patch, run autoconf, run configure, and compile again. Does
compilation work now?
(Can others check that this patch makes sense?)
*** emacs/configure.in.~1.414.~ 2006-10-28 16:35:50.000000000 -0400
--- emacs/configure.in 2006-10-29 18:23:16.000000000 -0500
***************
*** 1315,1320 ****
--- 1315,1322 ----
dnl Treat GCC specially since it just gives a non-fatal `unrecognized option'
dnl if not built to support GNU ld.
+ SPECIFIED_LDFLAGS=$LDFLAGS
+ AC_SUBST(SPECIFIED_LDFLAGS)
late_LDFLAGS=$LDFLAGS
if test "$GCC" = yes; then
LDFLAGS="$LDFLAGS -Wl,-znocombreloc"
*** emacs/src/Makefile.in.~1.331.~ 2006-09-16 09:28:06.000000000 -0400
--- emacs/src/Makefile.in 2006-10-29 18:24:35.000000000 -0500
***************
*** 444,450 ****
#ifdef HAVE_X11
/* LD_SWITCH_X_DEFAULT comes after everything else that specifies
options for where to find X libraries, but before those libraries. */
! X11_LDFLAGS = LD_SWITCH_X_SITE LD_SWITCH_X_DEFAULT
LIBX= $(LIBXMENU) $(X11_LDFLAGS) $(LIBXT) LIBTIFF LIBJPEG LIBPNG LIBGIF LIBXPM LIB_X11_LIB LIBX11_MACHINE LIBX11_SYSTEM
#else /* not HAVE_X11 */
LIBX= $(LIBXMENU) LD_SWITCH_X_SITE -lX10 LIBX10_MACHINE LIBX10_SYSTEM
--- 444,450 ----
#ifdef HAVE_X11
/* LD_SWITCH_X_DEFAULT comes after everything else that specifies
options for where to find X libraries, but before those libraries. */
! X11_LDFLAGS = @SPECIFIED_LDFLAGS@ LD_SWITCH_X_SITE LD_SWITCH_X_DEFAULT
LIBX= $(LIBXMENU) $(X11_LDFLAGS) $(LIBXT) LIBTIFF LIBJPEG LIBPNG LIBGIF LIBXPM LIB_X11_LIB LIBX11_MACHINE LIBX11_SYSTEM
#else /* not HAVE_X11 */
LIBX= $(LIBXMENU) LD_SWITCH_X_SITE -lX10 LIBX10_MACHINE LIBX10_SYSTEM
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-10-29 23:40 ` Pretest Chong Yidong
@ 2006-10-30 0:33 ` Alfred M. Szmidt
2006-10-30 14:12 ` Pretest Chong Yidong
0 siblings, 1 reply; 172+ messages in thread
From: Alfred M. Szmidt @ 2006-10-30 0:33 UTC (permalink / raw)
Cc: emacs-devel
> The reason from the looks is that the library search path is not
> propagated correctly. This is what config.log contains (tiff is
> installed in /usr/local):
>
> But at linking, none of the search paths are passed, and hence the
> missing library error.
I'm guessing you're passing an LDFLAGS envvar to configure. Seems
like LDFLAGS isn't getting passed to X11_LDFLAGS.
I'm not passing any flags to configure, it is a simple `./configure &&
make' deal.
Does compilation work now?
No, it doesn't. The value of X11_LDFLAGS is `-L/usr/X11R6/lib'.
Sorry that I can't be of much use fixing this, to much on my own
plate. :-(
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-10-29 21:36 ` Pretest Chong Yidong
@ 2006-10-30 4:25 ` Eli Zaretskii
2006-10-30 14:21 ` Pretest Chong Yidong
0 siblings, 1 reply; 172+ messages in thread
From: Eli Zaretskii @ 2006-10-30 4:25 UTC (permalink / raw)
Cc: emacs-devel
> Cc: emacs-devel@gnu.org
> From: Chong Yidong <cyd@stupidchicken.com>
> Date: Sun, 29 Oct 2006 16:36:41 -0500
>
> >> cd $(srcdir); $(MAKEINFO) elisp.texi
> >
> > I have no objections to such a change, but note that $(MAKEINFO)
> > doesn't include the -I switches in lispref/Makefile.in, so if we want
> > to make such a change, we should probably add them to the macro.
>
> I've checked such a change.
Yes, but you also changed makefile.w32-in, which breaks the Windows
build because the stock Windows shell doesn't support the `cmd1; cmd2'
method of having several commands on the same line. Please revert
that; the Windows build doesn't need that change, since it sets srcdir
to . anyway.
Btw, while looking at this, I found that several directories in the
tarball lack the makefile.w32-in file. These are: man, lispref, and
lispintro. Please modify make-dist to include them.
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-10-29 7:43 ` Pretest Eli Zaretskii
2006-10-29 22:11 ` Pretest Chong Yidong
@ 2006-10-30 13:33 ` Richard Stallman
2006-10-30 21:02 ` Pretest Eli Zaretskii
1 sibling, 1 reply; 172+ messages in thread
From: Richard Stallman @ 2006-10-30 13:33 UTC (permalink / raw)
Cc: cyd, emacs-devel
I don't know when I'll have time to do that; fencepost.gnu.org is not
my main machine. Even if I do find the portion of the diffs that
causes the problem, then what? We don't have a version of Autoconf
that would have the effect of applying only part of the diffs, so once
again we will be in a position where regenerating the configure script
would be difficult of impossible.
I have not followed the whole thread, and I am not certain I understand
the issue. Is the problem is that a certain snapshot of Autoconf
gives an incorrect configure file?
if so, we should never use that version of Autoconf to generate the
configure file, and we should report the bug to the Autoconf
developers.
Yidong, can you install a released Autoconf on your machine
and use that from now on?
However, in this case, config.in and config.h are identical to the
ones you included in the tarball, and so is src/Makefile.in. Am I
missing something?
That puzzles me, too.
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-10-29 11:47 ` Pretest Eli Zaretskii
@ 2006-10-30 13:33 ` Richard Stallman
2006-10-30 21:12 ` Pretest Eli Zaretskii
0 siblings, 1 reply; 172+ messages in thread
From: Richard Stallman @ 2006-10-30 13:33 UTC (permalink / raw)
Cc: cyd, emacs-devel, jasonr
Yes (that's what the Unix build does), but I'm reluctant to do that
now, since it would be a major change in the Windows build procedure.
I don't know the Windows build code, but I'd expect this to be a
fairly small change. And since it only has to run on one system, once
it is working for one of you, there's not a big chance it will fail
elsewhere.
Anyway, keeping things similar from system to system tends to be cleaner.
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-10-30 0:33 ` Pretest Alfred M. Szmidt
@ 2006-10-30 14:12 ` Chong Yidong
2006-10-30 19:57 ` Pretest Alfred M. Szmidt
0 siblings, 1 reply; 172+ messages in thread
From: Chong Yidong @ 2006-10-30 14:12 UTC (permalink / raw)
Cc: emacs-devel
"Alfred M. Szmidt" <ams@gnu.org> writes:
> I'm guessing you're passing an LDFLAGS envvar to configure. Seems
> like LDFLAGS isn't getting passed to X11_LDFLAGS.
>
> I'm not passing any flags to configure, it is a simple `./configure &&
> make' deal.
Then how did configure know to use -L/usr/pkg/lib and -L/usr/local/lib
in the excerpt you sent earlier?
configure:12671: gcc -o conftest -I/usr/X11R6/include -g -O2
-I/usr/X11R6/include -I/usr/X11R6/include -I/usr/pkg/include
-I/usr/local/include -L/usr/pkg/lib -L/usr/local/lib
-Wl,-znocombreloc -L/usr/X11R6/lib conftest.c -ltiff -ljpeg -lz -lm
-lXext -lXmu -lXt -lSM -lICE -lX11 >&5 -Z
In contrast, I have
configure:12672: gcc -o conftest -g -O2 -Wno-pointer-sign
-I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include
-I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -D_BSD_SOURCE
-Wl,-znocombreloc -L/usr/X11R6/lib conftest.c -ltiff -ljpeg -lz -lm
-lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm
-lpangocairo-1.0 -lfontconfig -lXext -lXrender -lXinerama -lXi
-lXrandr -lXcursor -lXfixes -lpango-1.0 -lcairo -lX11 -lgobject-2.0
-lgmodule-2.0 -ldl -lglib-2.0 -lX11 >&5
where only -L/usr/X11R6/lib is used. What is the value of LDFLAGS in
your default shell?
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-10-30 4:25 ` Pretest Eli Zaretskii
@ 2006-10-30 14:21 ` Chong Yidong
0 siblings, 0 replies; 172+ messages in thread
From: Chong Yidong @ 2006-10-30 14:21 UTC (permalink / raw)
Cc: emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> I've checked such a change.
>
> Yes, but you also changed makefile.w32-in, which breaks the Windows
> build because the stock Windows shell doesn't support the `cmd1; cmd2'
> method of having several commands on the same line. Please revert
> that; the Windows build doesn't need that change, since it sets srcdir
> to . anyway.
OK done; sorry for the inconvenience.
> Btw, while looking at this, I found that several directories in the
> tarball lack the makefile.w32-in file. These are: man, lispref, and
> lispintro. Please modify make-dist to include them.
Done.
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-10-29 20:22 ` Pretest Eli Zaretskii
@ 2006-10-30 19:16 ` Richard Stallman
0 siblings, 0 replies; 172+ messages in thread
From: Richard Stallman @ 2006-10-30 19:16 UTC (permalink / raw)
Cc: cyd, emacs-devel
I think emacs-pretest-bug@gnu.org is the right address to put there.
Ok, that makes sense.
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-10-30 14:12 ` Pretest Chong Yidong
@ 2006-10-30 19:57 ` Alfred M. Szmidt
2006-10-30 20:18 ` Pretest Chong Yidong
0 siblings, 1 reply; 172+ messages in thread
From: Alfred M. Szmidt @ 2006-10-30 19:57 UTC (permalink / raw)
Cc: emacs-devel
What is the value of LDFLAGS in your default shell?
It is not set.
I did some digging, the values are from `libsrc_libs' in configure.in
(they get pulled in from C_SWITCH_SYSTEM which is defined in netbsd.h;
which OpenBSD uses). The following patch works for me.
diff -up /home/ams/emacs-22.0.90/src/Makefile.in.\~2\~ /home/ams/emacs-22.0.90/src/Makefile.in
--- /home/ams/emacs-22.0.90/src/Makefile.in.~2~ 2006-10-30 03:03:56.000000000 +0100
+++ /home/ams/emacs-22.0.90/src/Makefile.in 2006-10-30 22:34:30.000000000 +0100
@@ -444,7 +444,7 @@ LIBXT=$(LIBW)
#ifdef HAVE_X11
/* LD_SWITCH_X_DEFAULT comes after everything else that specifies
options for where to find X libraries, but before those libraries. */
-X11_LDFLAGS = LD_SWITCH_X_SITE LD_SWITCH_X_DEFAULT
+X11_LDFLAGS = C_SWITCH_SYSTEM LD_SWITCH_X_SITE LD_SWITCH_X_DEFAULT
LIBX= $(LIBXMENU) $(X11_LDFLAGS) $(LIBXT) LIBTIFF LIBJPEG LIBPNG LIBGIF LIBXPM LIB_X11_LIB LIBX11_MACHINE LIBX11_SYSTEM
#else /* not HAVE_X11 */
LIBX= $(LIBXMENU) LD_SWITCH_X_SITE -lX10 LIBX10_MACHINE LIBX10_SYSTEM
Diff finished. Mon Oct 30 22:38:54 2006
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-10-27 17:59 Pretest Chong Yidong
` (14 preceding siblings ...)
2006-10-28 18:13 ` Pretest Richard Stallman
@ 2006-10-30 20:04 ` Paul Jarc
2006-10-30 23:13 ` Pretest Chong Yidong
2006-10-31 9:44 ` Pretest Jim Thompson
2006-11-05 23:30 ` Pretest Bill Wohler
17 siblings, 1 reply; 172+ messages in thread
From: Paul Jarc @ 2006-10-30 20:04 UTC (permalink / raw)
Chong Yidong <cyd@stupidchicken.com> wrote:
> ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-22.0.90.tar.gz
I had one problem building from this tarball. I have some headers
installed in unusual places, so I pass the appropriate -I flags in
CPPFLAGS. But lwlib/Makefile.in does not use CPPFLAGS in the rule for
lwlib.o, so I had some missing-header errors. When I added CPPFLAGS
to that rule, everything worked.
paul
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-10-30 19:57 ` Pretest Alfred M. Szmidt
@ 2006-10-30 20:18 ` Chong Yidong
2006-10-30 20:34 ` Pretest Alfred M. Szmidt
0 siblings, 1 reply; 172+ messages in thread
From: Chong Yidong @ 2006-10-30 20:18 UTC (permalink / raw)
Cc: emacs-devel
"Alfred M. Szmidt" <ams@gnu.org> writes:
> I did some digging, the values are from `libsrc_libs' in configure.in
> (they get pulled in from C_SWITCH_SYSTEM which is defined in netbsd.h;
> which OpenBSD uses). The following patch works for me.
>
> -X11_LDFLAGS = LD_SWITCH_X_SITE LD_SWITCH_X_DEFAULT
> +X11_LDFLAGS = C_SWITCH_SYSTEM LD_SWITCH_X_SITE LD_SWITCH_X_DEFAULT
I think it should be LD_SWITCH_SYSTEM, not C_SWITCH_SYSTEM. Does
using LD_SWITCH_SYSTEM instead work?
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-10-30 20:18 ` Pretest Chong Yidong
@ 2006-10-30 20:34 ` Alfred M. Szmidt
2006-10-30 22:18 ` Pretest Chong Yidong
2006-11-01 2:12 ` Pretest Richard Stallman
0 siblings, 2 replies; 172+ messages in thread
From: Alfred M. Szmidt @ 2006-10-30 20:34 UTC (permalink / raw)
Cc: emacs-devel
> I did some digging, the values are from `libsrc_libs' in
> configure.in (they get pulled in from C_SWITCH_SYSTEM which is
> defined in netbsd.h; which OpenBSD uses). The following patch
> works for me.
>
> -X11_LDFLAGS = LD_SWITCH_X_SITE LD_SWITCH_X_DEFAULT
> +X11_LDFLAGS = C_SWITCH_SYSTEM LD_SWITCH_X_SITE LD_SWITCH_X_DEFAULT
I think it should be LD_SWITCH_SYSTEM, not C_SWITCH_SYSTEM. Does
using LD_SWITCH_SYSTEM instead work?
No. LD_SWITCH_SYSTEM won't work because it isn't set on OpenBSD.
>From src/s/openbsd.h:
| ...
| #undef LD_SWITCH_SYSTEM_TEMACS
| #undef LD_SWITCH_SYSTEM
| ...
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-10-30 13:33 ` Pretest Richard Stallman
@ 2006-10-30 21:02 ` Eli Zaretskii
2006-11-01 2:12 ` Pretest Richard Stallman
0 siblings, 1 reply; 172+ messages in thread
From: Eli Zaretskii @ 2006-10-30 21:02 UTC (permalink / raw)
Cc: cyd, emacs-devel
> From: Richard Stallman <rms@gnu.org>
> CC: cyd@stupidchicken.com, emacs-devel@gnu.org
> Date: Mon, 30 Oct 2006 08:33:04 -0500
>
> I have not followed the whole thread, and I am not certain I understand
> the issue. Is the problem is that a certain snapshot of Autoconf
> gives an incorrect configure file?
The problem was that ld failed to link temacs without any error
message, and regenerating the configure script with a slightly
different version of Autoconf mysteriously solved the problem,
although I see no changes whatsoever except a few insignificant ones
in the configure script itself.
> if so, we should never use that version of Autoconf to generate the
> configure file, and we should report the bug to the Autoconf
> developers.
I'd like first to understand how come this caused ld to fail.
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-10-30 13:33 ` Pretest Richard Stallman
@ 2006-10-30 21:12 ` Eli Zaretskii
2006-11-01 2:12 ` Pretest Richard Stallman
0 siblings, 1 reply; 172+ messages in thread
From: Eli Zaretskii @ 2006-10-30 21:12 UTC (permalink / raw)
Cc: cyd, emacs-devel, jasonr
> From: Richard Stallman <rms@gnu.org>
> CC: jasonr@gnu.org, cyd@stupidchicken.com, emacs-devel@gnu.org
> Date: Mon, 30 Oct 2006 08:33:15 -0500
>
> I don't know the Windows build code, but I'd expect this to be a
> fairly small change. And since it only has to run on one system, once
> it is working for one of you, there's not a big chance it will fail
> elsewhere.
It is not a small change. It requires to move portions of
lib-src/makefile.w32-in to src/makefile.w32-in, and then making
corresponding changes in nt/makefile.w32-in. The moved portions
should work both for normal build and for bootstrap.
The Windows build is generally quite fragile, since it needs to
support a variety of Windows versions and shells, both stock Windows
shells (some of which are very stupid) and ported Unix shells, and
also a variety of ports of cp, mv, etc. Some Windows versions are not
in use by the Emacs developers, so we have no good way of testing such
non-trivial changes. That is why I think we can live with the few
minor problems until after the release.
> Anyway, keeping things similar from system to system tends to be cleaner.
I agree.
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-10-29 22:11 ` Pretest Chong Yidong
@ 2006-10-30 21:50 ` Eli Zaretskii
2006-10-30 22:04 ` Pretest Chong Yidong
0 siblings, 1 reply; 172+ messages in thread
From: Eli Zaretskii @ 2006-10-30 21:50 UTC (permalink / raw)
Cc: emacs-devel
> Cc: emacs-devel@gnu.org
> From: Chong Yidong <cyd@stupidchicken.com>
> Date: Sun, 29 Oct 2006 17:11:56 -0500
>
> You may be right. I downgraded autoconf to version 2.59-5, and
> regenerated configure in CVS. Can you try with this version and see
> if compilation works?
Something very strange is going on here: I unpacked the pretest
tarball in a different directory, and it builds there even with the
original configure script.
So I think the configure script is not the problem here. I will try
to look deeper when I have time; in the meantime, let's continue the
pretest as if this problem never happened.
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-10-30 21:50 ` Pretest Eli Zaretskii
@ 2006-10-30 22:04 ` Chong Yidong
2006-10-31 4:09 ` Pretest Eli Zaretskii
0 siblings, 1 reply; 172+ messages in thread
From: Chong Yidong @ 2006-10-30 22:04 UTC (permalink / raw)
Cc: emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
> Something very strange is going on here: I unpacked the pretest
> tarball in a different directory, and it builds there even with the
> original configure script.
>
> So I think the configure script is not the problem here. I will try
> to look deeper when I have time; in the meantime, let's continue the
> pretest as if this problem never happened.
I wonder if this is related to the problem reported by Martin Ebourne
<lists@ebourne.me.uk> in the thread "Small fix to configure.in in
CVS". He said:
> > The problem I had was that I was building to a prefix directory that
> > included the word 'linux'. The emacs configure was preprocessing the
> > Makefile through the C preprocessor, and this was substituting
> > 'linux' to 1, thus making all the paths invalid.
I haven't checked in the patch he supplied yet, since I was trying to
figure out whether the problem really exists. However, if the patch
fixes the problem for you, I guess we should check it in.
--- emacs/configure.in~ 2006-09-28 06:47:26.000000000 +0100
+++ emacs/configure.in 2006-10-25 13:50:29.000000000 +0100
@@ -3230,7 +3230,7 @@
# the C preprocessor to some helpful value like 1, or maybe the empty
# string. Needless to say consequent macro substitutions are less
# than conducive to the makefile finding the correct directory.
-[undefs="`echo $top_srcdir $configuration $canonical |
+[undefs="`echo $ac_top_srcdir $configuration $canonical |
sed -e 's/[^a-zA-Z0-9_]/ /g' -e 's/^/ /' -e 's/ *$//' \
-e 's/ */ -U/g' -e 's/-U[0-9][^ ]*//g' \
`"]
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-10-30 20:34 ` Pretest Alfred M. Szmidt
@ 2006-10-30 22:18 ` Chong Yidong
2006-10-30 23:00 ` Pretest Alfred M. Szmidt
2006-11-01 2:12 ` Pretest Richard Stallman
1 sibling, 1 reply; 172+ messages in thread
From: Chong Yidong @ 2006-10-30 22:18 UTC (permalink / raw)
Cc: emacs-devel
"Alfred M. Szmidt" <ams@gnu.org> writes:
> > -X11_LDFLAGS = LD_SWITCH_X_SITE LD_SWITCH_X_DEFAULT
> > +X11_LDFLAGS = C_SWITCH_SYSTEM LD_SWITCH_X_SITE LD_SWITCH_X_DEFAULT
>
> I think it should be LD_SWITCH_SYSTEM, not C_SWITCH_SYSTEM. Does
> using LD_SWITCH_SYSTEM instead work?
>
> No. LD_SWITCH_SYSTEM won't work because it isn't set on OpenBSD.
In that case, does the following change work?
*** emacs/src/s/openbsd.h.~1.6.~ 2005-03-21 12:33:04.000000000 -0500
--- emacs/src/s/openbsd.h 2006-10-30 17:12:53.000000000 -0500
***************
*** 23,29 ****
/* Han Boetes <han@mijncomputer.nl> says this
is necessary, otherwise Emacs dumps core on elf systems. */
! #define LD_SWITCH_SYSTEM LD_SWITCH_SYSTEM_tmp -Z
#else
--- 23,29 ----
/* Han Boetes <han@mijncomputer.nl> says this
is necessary, otherwise Emacs dumps core on elf systems. */
! #define LD_SWITCH_SYSTEM LD_SWITCH_SYSTEM_tmp -Z -L/usr/pkg/lib -L/usr/local/lib
#else
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-10-30 22:18 ` Pretest Chong Yidong
@ 2006-10-30 23:00 ` Alfred M. Szmidt
0 siblings, 0 replies; 172+ messages in thread
From: Alfred M. Szmidt @ 2006-10-30 23:00 UTC (permalink / raw)
Cc: emacs-devel
In that case, does the following change work?
Yeah, this seems to work. It should probobly be added in the non-ELF
case too. Thanks!
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-10-30 20:04 ` Pretest Paul Jarc
@ 2006-10-30 23:13 ` Chong Yidong
0 siblings, 0 replies; 172+ messages in thread
From: Chong Yidong @ 2006-10-30 23:13 UTC (permalink / raw)
Cc: prj
prj@po.cwru.edu (Paul Jarc) writes:
> I had one problem building from this tarball. I have some headers
> installed in unusual places, so I pass the appropriate -I flags in
> CPPFLAGS. But lwlib/Makefile.in does not use CPPFLAGS in the rule for
> lwlib.o, so I had some missing-header errors. When I added CPPFLAGS
> to that rule, everything worked.
I've checked in a fix to CVS. Thanks.
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-10-30 22:04 ` Pretest Chong Yidong
@ 2006-10-31 4:09 ` Eli Zaretskii
0 siblings, 0 replies; 172+ messages in thread
From: Eli Zaretskii @ 2006-10-31 4:09 UTC (permalink / raw)
Cc: emacs-devel
> Cc: emacs-devel@gnu.org
> From: Chong Yidong <cyd@stupidchicken.com>
> Date: Mon, 30 Oct 2006 17:04:50 -0500
>
> I wonder if this is related to the problem reported by Martin Ebourne
> <lists@ebourne.me.uk> in the thread "Small fix to configure.in in
> CVS". He said:
>
> > > The problem I had was that I was building to a prefix directory that
> > > included the word 'linux'. The emacs configure was preprocessing the
> > > Makefile through the C preprocessor, and this was substituting
> > > 'linux' to 1, thus making all the paths invalid.
But in my case, there's no `linux' in the directory's prefix, and I
don't think any of the paths are invalid, or I'd see a much more noisy
failures.
> I haven't checked in the patch he supplied yet, since I was trying to
> figure out whether the problem really exists. However, if the patch
> fixes the problem for you, I guess we should check it in.
I think I need to understand exactly why ld fails, because this looks
like a Heisenbug: seemingly innocent changes make it disappear.
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-10-27 17:59 Pretest Chong Yidong
` (15 preceding siblings ...)
2006-10-30 20:04 ` Pretest Paul Jarc
@ 2006-10-31 9:44 ` Jim Thompson
2006-11-05 23:30 ` Pretest Bill Wohler
17 siblings, 0 replies; 172+ messages in thread
From: Jim Thompson @ 2006-10-31 9:44 UTC (permalink / raw)
Chong Yidong <cyd <at> stupidchicken.com> writes:
>
> With Richard's agreement, I've bumped the version number to 22.0.90
> and rolled a pretest tarball. The tarball can be found at
>
> ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-22.0.90.tar.gz
Building on MacOS X fails. The target
../mac/Emacs.app/Contents/Resources/Emacs.icns
referenced by the target 'macos-bund' can't be resolved.
I used the file found here:
http://www2.ing.unipi.it/~d9615/homepage/mac/myemacs.icns
copied to mac/Emacs.app/Contents/Resources/Emacs.icns
and the build completed.
I then re-ran 'configure', passing it --enable-carbon-app'
(I'd left out '--enable-carbon-app' on the first run),
followed by 'make install', and all that seemed to work.
You might want to populate .../mac/Emacs.app/Contents/Resource/Emacs.icns
mac/ChangeLog says it should be there:
---
2002-07-01 Andrew Choi <akochoi@shaw.ca>
* Emacs.app/Contents/Resources/Emacs.icns: New file.
---
Thanks!
Jim
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-10-30 20:34 ` Pretest Alfred M. Szmidt
2006-10-30 22:18 ` Pretest Chong Yidong
@ 2006-11-01 2:12 ` Richard Stallman
2006-11-02 14:10 ` Pretest Alfred M. Szmidt
1 sibling, 1 reply; 172+ messages in thread
From: Richard Stallman @ 2006-11-01 2:12 UTC (permalink / raw)
Cc: cyd, emacs-devel
> -X11_LDFLAGS = LD_SWITCH_X_SITE LD_SWITCH_X_DEFAULT
> +X11_LDFLAGS = C_SWITCH_SYSTEM LD_SWITCH_X_SITE LD_SWITCH_X_DEFAULT
I think it should be LD_SWITCH_SYSTEM, not C_SWITCH_SYSTEM. Does
using LD_SWITCH_SYSTEM instead work?
No. LD_SWITCH_SYSTEM won't work because it isn't set on OpenBSD.
Neither one belongs in X11_LDFLAGS. X11_LDFLAGS is supposed to be the
_additional_ flags needed before the X libraries. Changing it on an
ad hoc basis just because it makes one bug disappear is the wrong way to
maintain Makefile.in.
The right thing to do is to change LD_SWITCH_X_DEFAULT.
(Changing LD_SWITCH_SYSTEM might also be an ok approach.)
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-10-30 21:02 ` Pretest Eli Zaretskii
@ 2006-11-01 2:12 ` Richard Stallman
2006-11-01 4:14 ` Pretest Eli Zaretskii
0 siblings, 1 reply; 172+ messages in thread
From: Richard Stallman @ 2006-11-01 2:12 UTC (permalink / raw)
Cc: cyd, emacs-devel
The problem was that ld failed to link temacs without any error
message, and regenerating the configure script with a slightly
different version of Autoconf mysteriously solved the problem,
although I see no changes whatsoever except a few insignificant ones
in the configure script itself.
It is quite mysterious, so I would suggest adding some echo statements
just before the ld command (in both cases), to verify the arguments
and environment.
plus echo's to
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-10-30 21:12 ` Pretest Eli Zaretskii
@ 2006-11-01 2:12 ` Richard Stallman
0 siblings, 0 replies; 172+ messages in thread
From: Richard Stallman @ 2006-11-01 2:12 UTC (permalink / raw)
Cc: cyd, emacs-devel, jasonr
It is not a small change. It requires to move portions of
lib-src/makefile.w32-in to src/makefile.w32-in, and then making
corresponding changes in nt/makefile.w32-in. The moved portions
should work both for normal build and for bootstrap.
In that case, I trust your judgment that we shouldn't do this now.
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-11-01 2:12 ` Pretest Richard Stallman
@ 2006-11-01 4:14 ` Eli Zaretskii
2006-11-02 4:42 ` Pretest Richard Stallman
0 siblings, 1 reply; 172+ messages in thread
From: Eli Zaretskii @ 2006-11-01 4:14 UTC (permalink / raw)
Cc: cyd, emacs-devel
> From: Richard Stallman <rms@gnu.org>
> CC: cyd@stupidchicken.com, emacs-devel@gnu.org
> Date: Tue, 31 Oct 2006 21:12:57 -0500
>
> The problem was that ld failed to link temacs without any error
> message, and regenerating the configure script with a slightly
> different version of Autoconf mysteriously solved the problem,
> although I see no changes whatsoever except a few insignificant ones
> in the configure script itself.
>
> It is quite mysterious, so I would suggest adding some echo statements
> just before the ld command (in both cases), to verify the arguments
> and environment.
The arguments are displayed by Make, and they are identical in both
cases.
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-11-01 4:14 ` Pretest Eli Zaretskii
@ 2006-11-02 4:42 ` Richard Stallman
2006-11-02 19:54 ` Pretest Eli Zaretskii
0 siblings, 1 reply; 172+ messages in thread
From: Richard Stallman @ 2006-11-02 4:42 UTC (permalink / raw)
Cc: cyd, emacs-devel
> It is quite mysterious, so I would suggest adding some echo statements
> just before the ld command (in both cases), to verify the arguments
> and environment.
The arguments are displayed by Make, and they are identical in both
cases.
What about the environment?
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-11-01 2:12 ` Pretest Richard Stallman
@ 2006-11-02 14:10 ` Alfred M. Szmidt
0 siblings, 0 replies; 172+ messages in thread
From: Alfred M. Szmidt @ 2006-11-02 14:10 UTC (permalink / raw)
Cc: cyd, emacs-devel
Would the following be OK? I haven't had a chance to test it but I
see no reason why it should not work.
2006-11-02 Alfred M. Szmidt <ams@gnu.org> (tiny change)
* s/openbsd.h (LD_SWITCH_SYSTEM): Remove /usr/pkg/lib and
/usr/pkg/lib from the library search path.
(LD_SWITCH_X_DEFAULT): New macro.
Index: openbsd.h
===================================================================
RCS file: /cvsroot/emacs/emacs/src/s/openbsd.h,v
retrieving revision 1.8
diff -u -p -r1.8 src/s/openbsd.h
*** src/s/openbsd.h 30 Oct 2006 23:05:35 -0000 1.8
--- src/s/openbsd.h 2 Nov 2006 14:05:03 -0000
***************
*** 23,33 ****
/* Han Boetes <han@mijncomputer.nl> says this
is necessary, otherwise Emacs dumps core on elf systems. */
! #define LD_SWITCH_SYSTEM LD_SWITCH_SYSTEM_tmp -Z -L/usr/pkg/lib -L/usr/local/lib
#else
! #define LD_SWITCH_SYSTEM LD_SWITCH_SYSTEM_tmp -L/usr/pkg/lib -L/usr/local/lib
#endif
--- 24,40 ----
/* Han Boetes <han@mijncomputer.nl> says this
is necessary, otherwise Emacs dumps core on elf systems. */
! #define LD_SWITCH_SYSTEM LD_SWITCH_SYSTEM_tmp -Z
!
! /* The version of gcc on OpenBSD doesn't search /usr/local/lib by
! default. */
! #define LD_SWITCH_X_DEFAULT -L/usr/local/lib
#else
! #define LD_SWITCH_SYSTEM LD_SWITCH_SYSTEM_tmp
!
! #define LD_SWITCH_X_DEFAULT -L/usr/local/lib
#endif
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-11-02 4:42 ` Pretest Richard Stallman
@ 2006-11-02 19:54 ` Eli Zaretskii
2006-11-03 7:08 ` Pretest Richard Stallman
0 siblings, 1 reply; 172+ messages in thread
From: Eli Zaretskii @ 2006-11-02 19:54 UTC (permalink / raw)
Cc: cyd, emacs-devel
> From: Richard Stallman <rms@gnu.org>
> CC: cyd@stupidchicken.com, emacs-devel@gnu.org
> Date: Wed, 01 Nov 2006 23:42:24 -0500
>
> > It is quite mysterious, so I would suggest adding some echo statements
> > just before the ld command (in both cases), to verify the arguments
> > and environment.
>
> The arguments are displayed by Make, and they are identical in both
> cases.
>
> What about the environment?
It's identical: I did both builds from the same account, just mkdir'ed
a subdirectory, chdir'ed there, unpacked the archive and built it.
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-11-02 19:54 ` Pretest Eli Zaretskii
@ 2006-11-03 7:08 ` Richard Stallman
2006-11-04 13:50 ` Pretest Eli Zaretskii
0 siblings, 1 reply; 172+ messages in thread
From: Richard Stallman @ 2006-11-03 7:08 UTC (permalink / raw)
Cc: cyd, emacs-devel
It's identical: I did both builds from the same account, just mkdir'ed
a subdirectory, chdir'ed there, unpacked the archive and built it.
We hope it is identical, but it would be useful to verify that
by adding printenv statements just before the invocations of ld.
If the difference isn't due to arguments and isn't due to the environment,
it must be due to something in the file system.
^ permalink raw reply [flat|nested] 172+ messages in thread
* RE: Pretest
2006-10-28 18:13 ` Pretest Richard Stallman
2006-10-28 19:02 ` Pretest Eli Zaretskii
@ 2006-11-03 15:39 ` Drew Adams
2006-11-03 19:22 ` Pretest Eli Zaretskii
` (2 more replies)
1 sibling, 3 replies; 172+ messages in thread
From: Drew Adams @ 2006-11-03 15:39 UTC (permalink / raw)
Not sure how the pretest works. Will binary versions be posted somewhere, or
will people need to roll their own?
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-11-03 15:39 ` Pretest Drew Adams
@ 2006-11-03 19:22 ` Eli Zaretskii
2006-11-03 19:51 ` Pretest Lennart Borgman
2006-11-03 20:48 ` Pretest Nick Roberts
2006-11-04 15:26 ` Pretest Richard Stallman
2 siblings, 1 reply; 172+ messages in thread
From: Eli Zaretskii @ 2006-11-03 19:22 UTC (permalink / raw)
Cc: emacs-devel
> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Fri, 3 Nov 2006 07:39:51 -0800
>
> Not sure how the pretest works. Will binary versions be posted somewhere, or
> will people need to roll their own?
The pretest includes only the source tarballs.
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-11-03 19:22 ` Pretest Eli Zaretskii
@ 2006-11-03 19:51 ` Lennart Borgman
2006-11-03 20:02 ` Pretest Eli Zaretskii
0 siblings, 1 reply; 172+ messages in thread
From: Lennart Borgman @ 2006-11-03 19:51 UTC (permalink / raw)
Cc: Drew Adams, emacs-devel
Eli Zaretskii wrote:
>> From: "Drew Adams" <drew.adams@oracle.com>
>> Date: Fri, 3 Nov 2006 07:39:51 -0800
>>
>> Not sure how the pretest works. Will binary versions be posted somewhere, or
>> will people need to roll their own?
>>
>
> The pretest includes only the source tarballs.
>
Is there any reason not to provide official binaries for those used to
that? At least for w32 I believe that would be an advantage.
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-11-03 19:51 ` Pretest Lennart Borgman
@ 2006-11-03 20:02 ` Eli Zaretskii
0 siblings, 0 replies; 172+ messages in thread
From: Eli Zaretskii @ 2006-11-03 20:02 UTC (permalink / raw)
Cc: drew.adams, emacs-devel
> Date: Fri, 03 Nov 2006 20:51:35 +0100
> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
> CC: Drew Adams <drew.adams@oracle.com>, emacs-devel@gnu.org
>
> Is there any reason not to provide official binaries for those used to
> that? At least for w32 I believe that would be an advantage.
The only reason is, as always, the need for someone to volunteer to do
that job. It's not part of the job description of the person who is
responsible for the pretest to do that.
For example, for MS-Windows, all that is needed is for you to prepare
a new binary on your site whenever a new pretest is rolled out.
^ permalink raw reply [flat|nested] 172+ messages in thread
* RE: Pretest
2006-11-03 15:39 ` Pretest Drew Adams
2006-11-03 19:22 ` Pretest Eli Zaretskii
@ 2006-11-03 20:48 ` Nick Roberts
2006-11-04 15:26 ` Pretest Richard Stallman
2 siblings, 0 replies; 172+ messages in thread
From: Nick Roberts @ 2006-11-03 20:48 UTC (permalink / raw)
Cc: emacs-devel
Drew Adams writes:
> Not sure how the pretest works. Will binary versions be posted somewhere, or
> will people need to roll their own?
AFAIK the pretest is a source tarball and hopefully most bug reports will just
be about its failure to build. The executable itself having been extensively
tested over the years from CVS.
--
Nick http://www.inet.net.nz/~nickrob
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-10-29 11:17 ` Pretest Jason Rumney
2006-10-29 11:47 ` Pretest Eli Zaretskii
@ 2006-11-04 12:15 ` Eli Zaretskii
2006-11-04 22:23 ` Pretest Jason Rumney
1 sibling, 1 reply; 172+ messages in thread
From: Eli Zaretskii @ 2006-11-04 12:15 UTC (permalink / raw)
Cc: emacs-devel
> Date: Sun, 29 Oct 2006 11:17:05 +0000
> From: Jason Rumney <jasonr@gnu.org>
> Cc: cyd@stupidchicken.com, emacs-devel@gnu.org
>
> Eli Zaretskii wrote:
> > Do you have some sh.exe on your PATH, or did you use CMD? I think my
> > patch would not work with CMD, due to forward slashes in the
> > redirection. I think I'd replace that with some cp command.
> >
> There is no sh.exe in my path, so I think it would have used cmd.exe.
> Perhaps mingw32-make converted the path before passing to cmd.exe?
It turns out that cmd.exe does grok redirection with forward slashes.
But command.com from Windows 9x won't.
> But cp would be safer.
I committed a change to use cp.
> >> But if temacs.exe is not needed to produce the DOC file, why do we
> >> depend on it in the first place?
> >>
> >
> > So that, whenever temacs.exe is rebuilt (meaning that some C file has
> > changed), DOC is regenerated by "make install".
> >
> Then wouldn't it be better to build DOC after temacs? Otherwise we lag
> behind by one build, since temacs does not get modified until after the
> DOC file is generated.
I asked why does temacs need to be modified when DOC is changed. Do
you know whether there's any need for that, and why?
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-11-03 7:08 ` Pretest Richard Stallman
@ 2006-11-04 13:50 ` Eli Zaretskii
2006-11-05 7:08 ` Pretest Richard Stallman
0 siblings, 1 reply; 172+ messages in thread
From: Eli Zaretskii @ 2006-11-04 13:50 UTC (permalink / raw)
Cc: cyd, emacs-devel
> From: Richard Stallman <rms@gnu.org>
> CC: cyd@stupidchicken.com, emacs-devel@gnu.org
> Date: Fri, 03 Nov 2006 02:08:20 -0500
>
> It's identical: I did both builds from the same account, just mkdir'ed
> a subdirectory, chdir'ed there, unpacked the archive and built it.
>
> We hope it is identical, but it would be useful to verify that
> by adding printenv statements just before the invocations of ld.
>
> If the difference isn't due to arguments and isn't due to the environment,
> it must be due to something in the file system.
As of now, I cannot even reproduce the original problem: with a fresh
source tree from the original tarball of the pretest, Emacs builds
without any problems on that machine. So I can only conclude that the
failure was due to some transient problem, perhaps indeed some screwup
in the file system that got fixed in the meantime.
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-11-03 15:39 ` Pretest Drew Adams
2006-11-03 19:22 ` Pretest Eli Zaretskii
2006-11-03 20:48 ` Pretest Nick Roberts
@ 2006-11-04 15:26 ` Richard Stallman
2 siblings, 0 replies; 172+ messages in thread
From: Richard Stallman @ 2006-11-04 15:26 UTC (permalink / raw)
Cc: emacs-devel
Not sure how the pretest works. Will binary versions be posted somewhere, or
will people need to roll their own?
We distribute pretests as source; we want pretesters to test the
build.
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-11-04 12:15 ` Pretest Eli Zaretskii
@ 2006-11-04 22:23 ` Jason Rumney
2006-11-05 6:15 ` Pretest Eli Zaretskii
0 siblings, 1 reply; 172+ messages in thread
From: Jason Rumney @ 2006-11-04 22:23 UTC (permalink / raw)
Cc: emacs-devel
Eli Zaretskii wrote:
> I asked why does temacs need to be modified when DOC is changed. Do
> you know whether there's any need for that, and why?
>
Isn't it the other way around? When temacs is changed, DOC needs to be
rebuilt?
The correct fix would seem to be to move building the DOC file from
lib-src/Makefile.w32-in to src/Makefile.w32-in like it is in the main
build, and build it after temacs.exe but before emacs.exe is dumped.
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-11-04 22:23 ` Pretest Jason Rumney
@ 2006-11-05 6:15 ` Eli Zaretskii
2006-11-05 12:39 ` Pretest Jason Rumney
2006-11-05 12:41 ` Pretest Jason Rumney
0 siblings, 2 replies; 172+ messages in thread
From: Eli Zaretskii @ 2006-11-05 6:15 UTC (permalink / raw)
Cc: emacs-devel
> Date: Sat, 04 Nov 2006 22:23:52 +0000
> From: Jason Rumney <jasonr@gnu.org>
> Cc: emacs-devel@gnu.org
>
> Eli Zaretskii wrote:
> > I asked why does temacs need to be modified when DOC is changed. Do
> > you know whether there's any need for that, and why?
>
> Isn't it the other way around? When temacs is changed, DOC needs to be
> rebuilt?
That we already do: this is why DOC depends on temacs.exe. Once
temacs.exe is rebuilt, "make install" will rebuild DOC.
But you seemed to say that this arrangement causes us to lag one step,
and I don't understand why.
> The correct fix would seem to be to move building the DOC file from
> lib-src/Makefile.w32-in to src/Makefile.w32-in like it is in the main
> build, and build it after temacs.exe but before emacs.exe is dumped.
Yes, but that's a non-trivial change that I'd rather not do before the
release, especially since there's no actual problem we need to solve.
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-11-04 13:50 ` Pretest Eli Zaretskii
@ 2006-11-05 7:08 ` Richard Stallman
0 siblings, 0 replies; 172+ messages in thread
From: Richard Stallman @ 2006-11-05 7:08 UTC (permalink / raw)
Cc: cyd, emacs-devel
As of now, I cannot even reproduce the original problem: with a fresh
source tree from the original tarball of the pretest, Emacs builds
without any problems on that machine. So I can only conclude that the
failure was due to some transient problem, perhaps indeed some screwup
in the file system that got fixed in the meantime.
Ok, we can stop worrying about this.
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-11-05 6:15 ` Pretest Eli Zaretskii
@ 2006-11-05 12:39 ` Jason Rumney
2006-11-05 12:41 ` Pretest Jason Rumney
1 sibling, 0 replies; 172+ messages in thread
From: Jason Rumney @ 2006-11-05 12:39 UTC (permalink / raw)
Cc: emacs-devel
Eli Zaretskii wrote:
> That we already do: this is why DOC depends on temacs.exe. Once
> temacs.exe is rebuilt, "make install" will rebuild DOC.
>
> But you seemed to say that this arrangement causes us to lag one step,
> and I don't understand why.
>
It lags behind in the case where the user does not "make install" after
every make. I'm not arguing with your desire to hold off on making any
changes until after the release though.
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-11-05 6:15 ` Pretest Eli Zaretskii
2006-11-05 12:39 ` Pretest Jason Rumney
@ 2006-11-05 12:41 ` Jason Rumney
1 sibling, 0 replies; 172+ messages in thread
From: Jason Rumney @ 2006-11-05 12:41 UTC (permalink / raw)
Cc: emacs-devel
Eli Zaretskii wrote:
> That we already do: this is why DOC depends on temacs.exe. Once
> temacs.exe is rebuilt, "make install" will rebuild DOC.
>
> But you seemed to say that this arrangement causes us to lag one step,
> and I don't understand why.
>
It lags behind in the case where the user does not "make install" after
every make. I'm not arguing with your desire to hold off on making any
changes until after the release though.
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-10-27 17:59 Pretest Chong Yidong
` (16 preceding siblings ...)
2006-10-31 9:44 ` Pretest Jim Thompson
@ 2006-11-05 23:30 ` Bill Wohler
2006-11-06 0:01 ` Pretest Jason Rumney
2006-11-06 4:22 ` Pretest Eli Zaretskii
17 siblings, 2 replies; 172+ messages in thread
From: Bill Wohler @ 2006-11-05 23:30 UTC (permalink / raw)
Chong Yidong <cyd@stupidchicken.com> writes:
> With Richard's agreement, I've bumped the version number to 22.0.90
> and rolled a pretest tarball.
Cool, thanks. I don't see a branch, so was it decided to branch closer
to the release?
--
Bill Wohler <wohler@newt.com> http://www.newt.com/wohler/ GnuPG ID:610BD9AD
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-11-05 23:30 ` Pretest Bill Wohler
@ 2006-11-06 0:01 ` Jason Rumney
2006-11-06 4:22 ` Pretest Eli Zaretskii
1 sibling, 0 replies; 172+ messages in thread
From: Jason Rumney @ 2006-11-06 0:01 UTC (permalink / raw)
Cc: emacs-devel
Bill Wohler wrote:
>> With Richard's agreement, I've bumped the version number to 22.0.90
>> and rolled a pretest tarball.
>>
>
> Cool, thanks. I don't see a branch, so was it decided to branch closer
> to the release?
>
The time to branch would be just before the emacs-unicode-2 branch is
merged to the trunk. I'd expect this to happen shortly after the release.
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-11-05 23:30 ` Pretest Bill Wohler
2006-11-06 0:01 ` Pretest Jason Rumney
@ 2006-11-06 4:22 ` Eli Zaretskii
1 sibling, 0 replies; 172+ messages in thread
From: Eli Zaretskii @ 2006-11-06 4:22 UTC (permalink / raw)
Cc: emacs-devel
> From: Bill Wohler <wohler@newt.com>
> Date: Sun, 05 Nov 2006 15:30:35 -0800
>
> Chong Yidong <cyd@stupidchicken.com> writes:
>
> > With Richard's agreement, I've bumped the version number to 22.0.90
> > and rolled a pretest tarball.
>
> Cool, thanks. I don't see a branch, so was it decided to branch closer
> to the release?
I think we branch _after_ the release.
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
@ 2006-11-07 20:13 Nick Roberts
2006-11-07 22:48 ` Pretest Miles Bader
0 siblings, 1 reply; 172+ messages in thread
From: Nick Roberts @ 2006-11-07 20:13 UTC (permalink / raw)
Cc: Chong Yidong, Bill Wohler, emacs-devel
> With Richard's agreement, I've bumped the version number to 22.0.90
> and rolled a pretest tarball.
>
>
> Cool, thanks. I don't see a branch, so was it decided to branch closer
> to the release?
>
>
> The time to branch would be just before the emacs-unicode-2 branch is merged
> to the trunk. I'd expect this to happen shortly after the release.
Doesn't the emacs-unicode-2 branch sync with the trunk. If that's the case,
won't emacs-unicode-2 just become the new trunk?
--
Nick http://www.inet.net.nz/~nickrob
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-11-07 20:13 Pretest Nick Roberts
@ 2006-11-07 22:48 ` Miles Bader
2006-11-08 1:17 ` Pretest Nick Roberts
0 siblings, 1 reply; 172+ messages in thread
From: Miles Bader @ 2006-11-07 22:48 UTC (permalink / raw)
Cc: Chong Yidong, emacs-devel, Bill Wohler, Jason Rumney
Nick Roberts <nickrob@snap.net.nz> writes:
>> The time to branch would be just before the emacs-unicode-2 branch is merged
>> to the trunk. I'd expect this to happen shortly after the release.
>
> Doesn't the emacs-unicode-2 branch sync with the trunk. If that's the case,
> won't emacs-unicode-2 just become the new trunk?
That's not how CVS works though, CVS has a distinguished trunk.
To make emacs-unicode-2 the trunk we have to merge it to the existing
trunk -- of course this should be almost trivial because conflicts are
resolved regularly these days.
-Miles
--
The car has become... an article of dress without which we feel uncertain,
unclad, and incomplete. [Marshall McLuhan, Understanding Media, 1964]
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-11-07 22:48 ` Pretest Miles Bader
@ 2006-11-08 1:17 ` Nick Roberts
2006-11-08 1:41 ` Pretest Miles Bader
0 siblings, 1 reply; 172+ messages in thread
From: Nick Roberts @ 2006-11-08 1:17 UTC (permalink / raw)
Cc: Chong Yidong, emacs-devel, Bill Wohler, Jason Rumney
> > Doesn't the emacs-unicode-2 branch sync with the trunk. If that's the
> > case, won't emacs-unicode-2 just become the new trunk?
>
> That's not how CVS works though, CVS has a distinguished trunk.
> To make emacs-unicode-2 the trunk we have to merge it to the existing
> trunk -- of course this should be almost trivial because conflicts are
> resolved regularly these days.
OK, but the merging is already being done on the emacs-unicode-2 branch.
Presumably if Bill (Wohler) has a new (untested) version of MH-E, say, for
Emacs 23, he could commit it now to emacs-unicode-2 i.e he doesn't need to wait
till after the release.
--
Nick http://www.inet.net.nz/~nickrob
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-11-08 1:17 ` Pretest Nick Roberts
@ 2006-11-08 1:41 ` Miles Bader
0 siblings, 0 replies; 172+ messages in thread
From: Miles Bader @ 2006-11-08 1:41 UTC (permalink / raw)
Cc: Chong Yidong, emacs-devel, Bill Wohler, Jason Rumney
Nick Roberts <nickrob@snap.net.nz> writes:
> OK, but the merging is already being done on the emacs-unicode-2
> branch. Presumably if Bill (Wohler) has a new (untested) version of
> MH-E, say, for Emacs 23, he could commit it now to emacs-unicode-2 i.e
> he doesn't need to wait till after the release.
He could indeed do that, though I don't think Richard wants people
generally to all move over to a branch for their hacking -- the trunk is
where the focus should be (and I gather this is one of the reasons for
not branching before the release actually happens).
I'd also think it would be polite to ask Kenichi before doing any
kind of big change on the unicode branch.
-Miles
--
"Though they may have different meanings, the cries of 'Yeeeee-haw!' and
'Allahu akbar!' are, in spirit, not actually all that different."
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-10-28 11:31 ` Pretest Eli Zaretskii
@ 2006-11-15 21:35 ` Reiner Steib
2006-11-15 22:51 ` Pretest Nick Roberts
0 siblings, 1 reply; 172+ messages in thread
From: Reiner Steib @ 2006-11-15 21:35 UTC (permalink / raw)
Cc: David Hansen, emacs-devel
On Sat, Oct 28 2006, Eli Zaretskii wrote:
>> From: David Hansen <david.hansen@gmx.net>
>> Date: Fri, 27 Oct 2006 21:12:03 +0200
>>
>> As there are already a lot of "normal" users out there who use
>> Emacs 22 for daily work why not gnu.emacs.help?
>
> If they already use the CVS code, they don't need the announcement, do
> they?
Probably some of them don't update from CVS frequently. The
availability of a pretest might encourage those to upgrade to the
pretest.
Bye, Reiner.
--
,,,
(o o)
---ooO-(_)-Ooo--- | PGP key available | http://rsteib.home.pages.de/
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-11-15 21:35 ` Pretest Reiner Steib
@ 2006-11-15 22:51 ` Nick Roberts
0 siblings, 0 replies; 172+ messages in thread
From: Nick Roberts @ 2006-11-15 22:51 UTC (permalink / raw)
Cc: Eli Zaretskii, David Hansen, emacs-devel
Reiner Steib writes:
> >> As there are already a lot of "normal" users out there who use
> >> Emacs 22 for daily work why not gnu.emacs.help?
> >
> > If they already use the CVS code, they don't need the announcement, do
> > they?
>
> Probably some of them don't update from CVS frequently. The
> availability of a pretest might encourage those to upgrade to the
> pretest.
Also if there are build problems with the tarball (the main purpose of the
pretest tarball?) then they won't be noticed just by using the CVS code.
--
Nick http://www.inet.net.nz/~nickrob
^ permalink raw reply [flat|nested] 172+ messages in thread
* Pretest
@ 2006-11-18 22:14 Chong Yidong
2006-11-18 22:58 ` Pretest Lennart Borgman
` (2 more replies)
0 siblings, 3 replies; 172+ messages in thread
From: Chong Yidong @ 2006-11-18 22:14 UTC (permalink / raw)
I've rolled a new pretest tarball, which is available at
ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-22.0.91.tar.gz
The various build problems in 22.0.90 should be resolved. We should
now make the pretest announcement, if Richard has finished updating
the pretesters list.
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-11-18 22:14 Pretest Chong Yidong
@ 2006-11-18 22:58 ` Lennart Borgman
2006-11-18 23:32 ` Pretest Chong Yidong
2006-11-19 0:56 ` Pretest Nick Roberts
2006-11-19 12:48 ` Pretest Richard Stallman
2006-11-19 19:59 ` Pretest Eli Zaretskii
2 siblings, 2 replies; 172+ messages in thread
From: Lennart Borgman @ 2006-11-18 22:58 UTC (permalink / raw)
Cc: emacs-devel
Chong Yidong wrote:
> I've rolled a new pretest tarball, which is available at
>
> ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-22.0.91.tar.gz
>
> The various build problems in 22.0.90 should be resolved. We should
> now make the pretest announcement, if Richard has finished updating
> the pretesters list.
We are currently working with emacsclient. It would be very good if our
changes in emacsclient were included in the pretest. We need a little
bit more time for resolving some issues and for testing.
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-11-18 22:58 ` Pretest Lennart Borgman
@ 2006-11-18 23:32 ` Chong Yidong
2006-11-19 0:53 ` Pretest Juanma Barranquero
2006-11-19 0:56 ` Pretest Nick Roberts
1 sibling, 1 reply; 172+ messages in thread
From: Chong Yidong @ 2006-11-18 23:32 UTC (permalink / raw)
Cc: emacs-devel
Lennart Borgman <lennart.borgman.073@student.lu.se> writes:
> Chong Yidong wrote:
>> I've rolled a new pretest tarball, which is available at
>>
>> ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-22.0.91.tar.gz
>>
>> The various build problems in 22.0.90 should be resolved. We should
>> now make the pretest announcement, if Richard has finished updating
>> the pretesters list.
>
> We are currently working with emacsclient. It would be very good if
> our changes in emacsclient were included in the pretest. We need a
> little bit more time for resolving some issues and for testing.
I didn't know there were still outstanding issues with emacsclient.
(I haven't been following the thread closely, but it's been a month
since the first batch of emacsclient changes were checked in, and
there hasn't been any email traffic on this issue lately, so I assume
the initial batch of bugs that surfaced has been fixed. Or haven't
they?) As for needing more time for testing... well, that's the whole
point of a preTEST.
In any case, there will be more pretests, so I think we should go
ahead and make the pretest announcement anyway.
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-11-18 23:32 ` Pretest Chong Yidong
@ 2006-11-19 0:53 ` Juanma Barranquero
0 siblings, 0 replies; 172+ messages in thread
From: Juanma Barranquero @ 2006-11-19 0:53 UTC (permalink / raw)
Cc: Lennart Borgman, emacs-devel
On 11/19/06, Chong Yidong <cyd@stupidchicken.com> wrote:
> I didn't know there were still outstanding issues with emacsclient.
> (I haven't been following the thread closely, but it's been a month
> since the first batch of emacsclient changes were checked in, and
> there hasn't been any email traffic on this issue lately, so I assume
> the initial batch of bugs that surfaced has been fixed. Or haven't
> they?)
Yes. There are no outstanding problems with emacsclient. Lennart is
trying to add functionality to allow emacsclient to start Emacs and
retry communication if Emacs is not running when emacsclient runs.
/L/e/k/t/u
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-11-18 22:58 ` Pretest Lennart Borgman
2006-11-18 23:32 ` Pretest Chong Yidong
@ 2006-11-19 0:56 ` Nick Roberts
2006-11-19 1:01 ` Pretest Juanma Barranquero
2006-11-19 8:45 ` Pretest David Kastrup
1 sibling, 2 replies; 172+ messages in thread
From: Nick Roberts @ 2006-11-19 0:56 UTC (permalink / raw)
Cc: Chong Yidong, emacs-devel
> > I've rolled a new pretest tarball, which is available at
> >
> > ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-22.0.91.tar.gz
> >
> > The various build problems in 22.0.90 should be resolved. We should
> > now make the pretest announcement, if Richard has finished updating
> > the pretesters list.
>
>
> We are currently working with emacsclient. It would be very good if our
> changes in emacsclient were included in the pretest. We need a little
> bit more time for resolving some issues and for testing.
It sounds like it's too late. If the issues can't be resolved quickly perhaps
the changes should be reverted.
--
Nick http://www.inet.net.nz/~nickrob
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-11-19 0:56 ` Pretest Nick Roberts
@ 2006-11-19 1:01 ` Juanma Barranquero
2006-11-19 1:56 ` Pretest Nick Roberts
2006-11-19 8:45 ` Pretest David Kastrup
1 sibling, 1 reply; 172+ messages in thread
From: Juanma Barranquero @ 2006-11-19 1:01 UTC (permalink / raw)
Cc: Lennart Borgman, Chong Yidong, emacs-devel
On 11/19/06, Nick Roberts <nickrob@snap.net.nz> wrote:
> It sounds like it's too late. If the issues can't be resolved quickly perhaps
> the changes should be reverted.
What issues? What changes should be reverted?
/L/e/k/t/u
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-11-19 1:01 ` Pretest Juanma Barranquero
@ 2006-11-19 1:56 ` Nick Roberts
2006-11-19 2:04 ` Pretest Juanma Barranquero
0 siblings, 1 reply; 172+ messages in thread
From: Nick Roberts @ 2006-11-19 1:56 UTC (permalink / raw)
Cc: Lennart Borgman, Chong Yidong, emacs-devel
> > It sounds like it's too late. If the issues can't be resolved quickly
> > perhaps the changes should be reverted.
>
> What issues?
You should ask Lennart that question.
> What changes should be reverted?
The ones which are causing the issues.
--
Nick http://www.inet.net.nz/~nickrob
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-11-19 1:56 ` Pretest Nick Roberts
@ 2006-11-19 2:04 ` Juanma Barranquero
2006-11-19 3:29 ` Pretest Nick Roberts
0 siblings, 1 reply; 172+ messages in thread
From: Juanma Barranquero @ 2006-11-19 2:04 UTC (permalink / raw)
Cc: Lennart Borgman, Chong Yidong, emacs-devel
On 11/19/06, Nick Roberts <nickrob@snap.net.nz> wrote:
> > What issues?
>
> You should ask Lennart that question.
I ask you because Lennart's changes aren't committed yet.
> > What changes should be reverted?
>
> The ones which are causing the issues.
What issues?
/L/e/k/t/u
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-11-19 2:04 ` Pretest Juanma Barranquero
@ 2006-11-19 3:29 ` Nick Roberts
0 siblings, 0 replies; 172+ messages in thread
From: Nick Roberts @ 2006-11-19 3:29 UTC (permalink / raw)
Cc: Lennart Borgman, Chong Yidong, emacs-devel
Juanma Barranquero writes:
> On 11/19/06, Nick Roberts <nickrob@snap.net.nz> wrote:
>
> > > What issues?
> >
> > You should ask Lennart that question.
>
> I ask you because Lennart's changes aren't committed yet.
Well I don't know. He stated that there were issues.
> > > What changes should be reverted?
> >
> > The ones which are causing the issues.
>
> What issues?
You remind me of a man.
What man?
A man with a power?
What power?
The power of hoodoo.
Who do?!
You do!
Do what?
Remind me of a man...
--
Nick http://www.inet.net.nz/~nickrob
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-11-19 0:56 ` Pretest Nick Roberts
2006-11-19 1:01 ` Pretest Juanma Barranquero
@ 2006-11-19 8:45 ` David Kastrup
2006-11-19 10:03 ` Pretest Nick Roberts
1 sibling, 1 reply; 172+ messages in thread
From: David Kastrup @ 2006-11-19 8:45 UTC (permalink / raw)
Cc: Lennart Borgman, Chong Yidong, emacs-devel
Nick Roberts <nickrob@snap.net.nz> writes:
> > > I've rolled a new pretest tarball, which is available at
> > >
> > > ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-22.0.91.tar.gz
> > >
> > > The various build problems in 22.0.90 should be resolved. We should
> > > now make the pretest announcement, if Richard has finished updating
> > > the pretesters list.
> >
> >
> > We are currently working with emacsclient. It would be very good if our
> > changes in emacsclient were included in the pretest. We need a little
> > bit more time for resolving some issues and for testing.
>
> It sounds like it's too late. If the issues can't be resolved
> quickly perhaps the changes should be reverted.
What sense is in reverting changes if it is too late?
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-11-19 8:45 ` Pretest David Kastrup
@ 2006-11-19 10:03 ` Nick Roberts
2006-11-19 10:18 ` Pretest David Kastrup
0 siblings, 1 reply; 172+ messages in thread
From: Nick Roberts @ 2006-11-19 10:03 UTC (permalink / raw)
Cc: Lennart Borgman, Chong Yidong, emacs-devel
> > > We are currently working with emacsclient. It would be very good if our
> > > changes in emacsclient were included in the pretest. We need a little
> > > bit more time for resolving some issues and for testing.
> >
> > It sounds like it's too late. If the issues can't be resolved
> > quickly perhaps the changes should be reverted.
>
> What sense is in reverting changes if it is too late?
Too late to include changes in a pretest that is already out! The changes were
made after the first pretest for a bug that was deemed non-critical by Richard.
It seems a bit rich to ask for more time a month later. If it's quicker to
revert them than to resolve then that seems to make sense to me.
--
Nick http://www.inet.net.nz/~nickrob
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-11-19 10:03 ` Pretest Nick Roberts
@ 2006-11-19 10:18 ` David Kastrup
2006-11-19 11:44 ` Pretest Nick Roberts
2006-11-20 1:37 ` Pretest Richard Stallman
0 siblings, 2 replies; 172+ messages in thread
From: David Kastrup @ 2006-11-19 10:18 UTC (permalink / raw)
Cc: Lennart Borgman, Chong Yidong, emacs-devel
Nick Roberts <nickrob@snap.net.nz> writes:
> > > > We are currently working with emacsclient. It would be very
> > > > good if our changes in emacsclient were included in the
> > > > pretest. We need a little bit more time for resolving some
> > > > issues and for testing.
> > >
> > > It sounds like it's too late. If the issues can't be resolved
> > > quickly perhaps the changes should be reverted.
> >
> > What sense is in reverting changes if it is too late?
>
> Too late to include changes in a pretest that is already out! The
> changes were made after the first pretest for a bug that was deemed
> non-critical by Richard. It seems a bit rich to ask for more time a
> month later. If it's quicker to revert them than to resolve then
> that seems to make sense to me.
It seems like we have completely different recollections of events.
As far as I remember, Richard oked getting emacsclient to work on
Windows even after the first pretest (where emacsclient was not yet a
part of Emacs).
There is no point whatsoever in reverting to the state of the first
pretest, namely "non-working". Whether there is sense to reverting to
a later point of development has not been discussed yet: up to now the
developers tried getting the functionality to do the right thing.
Telling them that they should stop doing so and revert to some earlier
stage would require agreement on just what this earlier state should
be. "non-working" is what you demand.
Up to now there has been no discussion about where we should exactly
draw the line with regard to emacsclient (work is still going on), but
I don't think that "non-working" would get much support.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-11-19 10:18 ` Pretest David Kastrup
@ 2006-11-19 11:44 ` Nick Roberts
2006-11-19 14:13 ` Pretest Juanma Barranquero
2006-11-19 14:19 ` Pretest Juanma Barranquero
2006-11-20 1:37 ` Pretest Richard Stallman
1 sibling, 2 replies; 172+ messages in thread
From: Nick Roberts @ 2006-11-19 11:44 UTC (permalink / raw)
Cc: Lennart Borgman, Chong Yidong, emacs-devel
Telling them that they should stop doing so and revert to some earlier
stage would require agreement on just what this earlier state should
be. "non-working" is what you demand.
I'm not telling people what to do, or demanding anything. I'm just saying that
I don't it is appropriate to delay things for further improvements to
emacsclient on Windows. If you're going to sum up, at least do it accurately.
--
Nick http://www.inet.net.nz/~nickrob
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-11-18 22:14 Pretest Chong Yidong
2006-11-18 22:58 ` Pretest Lennart Borgman
@ 2006-11-19 12:48 ` Richard Stallman
2006-11-19 20:08 ` Pretest Eli Zaretskii
2006-11-19 21:50 ` Pretest Reiner Steib
2006-11-19 19:59 ` Pretest Eli Zaretskii
2 siblings, 2 replies; 172+ messages in thread
From: Richard Stallman @ 2006-11-19 12:48 UTC (permalink / raw)
Cc: emacs-devel
I have updated the emacs-pretesters mailing list
and I will now send out a pretest announcement.
I think someone suggested using Reply-to to avoid encouraging people
to send all their replies to the emacs-pretesters list. That would
do the job if someone were doing "reply to sender", but if someone
does "reply all" it will still go to the list.
Would Mail-followup-to do the job?
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-11-19 11:44 ` Pretest Nick Roberts
@ 2006-11-19 14:13 ` Juanma Barranquero
2006-11-19 14:24 ` Pretest David Kastrup
2006-11-20 12:59 ` Pretest Richard Stallman
2006-11-19 14:19 ` Pretest Juanma Barranquero
1 sibling, 2 replies; 172+ messages in thread
From: Juanma Barranquero @ 2006-11-19 14:13 UTC (permalink / raw)
Cc: emacs-devel
On 11/19/06, Nick Roberts <nickrob@snap.net.nz> wrote:
> I'm not telling people what to do, or demanding anything. I'm just saying that
> I don't it is appropriate to delay things for further improvements to
> emacsclient on Windows. If you're going to sum up, at least do it accurately.
Well, if you're going to propose something, you should try to be
accurate too. Reading the relevant threads (or even reading this one
with a bit of attention to details) should suffice.
emacsclient's TCP support is working, and there are no issues.
Removing it now would be absurd.
Lennart is *proposing* changes that would allow emacsclient to
automatically start Emacs if it is not running already. Did you read
"Windows" in the previous sentence? I bet you didn't, because it *was
not* here. What Lennart's trying to do is not Windows-specific.
Whether it is too late to include it or not is another matter
altogether, but that can be discussed without the need to remove
working code.
/L/e/k/t/u
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-11-19 11:44 ` Pretest Nick Roberts
2006-11-19 14:13 ` Pretest Juanma Barranquero
@ 2006-11-19 14:19 ` Juanma Barranquero
1 sibling, 0 replies; 172+ messages in thread
From: Juanma Barranquero @ 2006-11-19 14:19 UTC (permalink / raw)
Cc: emacs-devel
On 11/19/06, Nick Roberts <nickrob@snap.net.nz> wrote:
> I'm not telling people what to do, or demanding anything. I'm just saying that
> I don't it is appropriate to delay things for further improvements to
> emacsclient on Windows. If you're going to sum up, at least do it accurately.
Well, if you're going to propose something, you should try to be
accurate too. Reading the relevant threads (or even reading this one
with a bit of attention to details) should suffice.
emacsclient's TCP support is working, and there are no issues.
Removing it now would be absurd.
Lennart is *proposing* changes that would allow emacsclient to
automatically start Emacs if it is not running already. Did you read
"Windows" in the previous sentence? I bet you didn't, because it *was
not* here. What Lennart's trying to do is not Windows-specific.
Whether it is too late to include it or not is another matter
altogether, but that can be discussed without the need to remove
working code.
/L/e/k/t/u
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-11-19 14:13 ` Pretest Juanma Barranquero
@ 2006-11-19 14:24 ` David Kastrup
2006-11-19 14:42 ` Pretest Juanma Barranquero
2006-11-19 14:45 ` Pretest Lennart Borgman
2006-11-20 12:59 ` Pretest Richard Stallman
1 sibling, 2 replies; 172+ messages in thread
From: David Kastrup @ 2006-11-19 14:24 UTC (permalink / raw)
Cc: Nick Roberts, emacs-devel
"Juanma Barranquero" <lekktu@gmail.com> writes:
> On 11/19/06, Nick Roberts <nickrob@snap.net.nz> wrote:
>
>> I'm not telling people what to do, or demanding anything. I'm just
>> saying that I don't it is appropriate to delay things for further
>> improvements to emacsclient on Windows. If you're going to sum up,
>> at least do it accurately.
>
> Lennart is *proposing* changes that would allow emacsclient to
> automatically start Emacs if it is not running already.
Could anybody summarize what is missing in order to make
emacsclient --alternate-editor "emacs --eval '(server-start)'"
work for this purpose? That seems simple enough, but I could be
likely missing some part of the picture.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-11-19 14:24 ` Pretest David Kastrup
@ 2006-11-19 14:42 ` Juanma Barranquero
2006-11-19 14:45 ` Pretest Lennart Borgman
1 sibling, 0 replies; 172+ messages in thread
From: Juanma Barranquero @ 2006-11-19 14:42 UTC (permalink / raw)
Cc: Nick Roberts, emacs-devel
On 11/19/06, David Kastrup <dak@gnu.org> wrote:
> Could anybody summarize what is missing in order to make
>
> emacsclient --alternate-editor "emacs --eval '(server-start)'"
>
> work for this purpose?
If you do
emacsclient -a "emacs --eval '(server-start)'" my-file.txt
and Emacs is running, Emacs will edit my-file.txt and emacsclient will wait.
If Emacs is not running, emacsclient will start Emacs (with the server
active) and pass it my-file.txt, but emacsclient won't have a
connection with Emacs so it won't wait for Emacs to finish.
emacsclient does not know (it never knew) how to start Emacs, then
wait for a while, then retry connection with it (which
gnuclient/gnuserv does, for example).
That is relevant if you're using emacsclient from a shortcut, or from
inside a program (for example, if you've set SVN_EDITOR to use Emacs
to edit Subversion commit logs, as I do).
There are a few related issues (quoting on the command line on
Windows, passing the server-name and server-file to Emacs if started
by emacsclient, not starting Emacs if the connection is not local,
etc.), but they're minor.
As it stands now, emacsclient is no less functional that it was before
the TCP changes. The behavior Lennart's trying to fix would happen
before. It is new (and very useful) functionality.
/L/e/k/t/u
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-11-19 14:24 ` Pretest David Kastrup
2006-11-19 14:42 ` Pretest Juanma Barranquero
@ 2006-11-19 14:45 ` Lennart Borgman
2006-11-19 15:58 ` Pretest David Kastrup
2006-11-19 17:54 ` Pretest Jason Rumney
1 sibling, 2 replies; 172+ messages in thread
From: Lennart Borgman @ 2006-11-19 14:45 UTC (permalink / raw)
Cc: Juanma Barranquero, Nick Roberts, emacs-devel
David Kastrup wrote:
> "Juanma Barranquero" <lekktu@gmail.com> writes:
>
>> On 11/19/06, Nick Roberts <nickrob@snap.net.nz> wrote:
>>
>>> I'm not telling people what to do, or demanding anything. I'm just
>>> saying that I don't it is appropriate to delay things for further
>>> improvements to emacsclient on Windows. If you're going to sum up,
>>> at least do it accurately.
>> Lennart is *proposing* changes that would allow emacsclient to
>> automatically start Emacs if it is not running already.
>
> Could anybody summarize what is missing in order to make
>
> emacsclient --alternate-editor "emacs --eval '(server-start)'"
>
> work for this purpose? That seems simple enough, but I could be
> likely missing some part of the picture.
Perhaps I could answer ;-)
What is missing is something that allows you to just use
emacsclient -n myfile
without doing any setup whatever, without having to start Emacs before.
It should in my opinion work right out of the box.
The reason? The threshold is already high to start to use Emacs. For new
users it is very important to be able to start immediately right after
installing Emacs. Otherwise a lot of potential user might never start
using Emacs.
The possibility to do something like the line you propose should still
be there, but with my patch you should be able to just use
emacsclient --alternative-editor="whateveryoulike" myfile
instead.
I have previously added similar functionality to gnuclient on w32. I
have waited for a working emacsclient on w32 so that I could try to
implement that feature there instead in a platform independent manner. I
have done that now - I believe. The code is working on w32 and most of
it is the same on other platforms. Starting a new process is however
platform dependent. I think there are three different platform dependent
ways:
- fork()
- CreateProcess() on w32
- system() -- needs a helper program to avoid wait
To be clear the code is there for all three ways (but it is not yet
submitted to the CVS). For those that does not want to use the new
functionality to start Emacs automatically everything will work as before.
When I started to distribute binaries for Emacs on w32 Richard expressed
that he wanted the official release of Emacs to have all functionality
it included working on GNU/Linux. My proposal above is not exactly in
line with that, but rather close. On w32 this functionality actually
have been available for quite some time now.
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-11-19 14:45 ` Pretest Lennart Borgman
@ 2006-11-19 15:58 ` David Kastrup
2006-11-19 19:13 ` Pretest Lennart Borgman
2006-11-19 17:54 ` Pretest Jason Rumney
1 sibling, 1 reply; 172+ messages in thread
From: David Kastrup @ 2006-11-19 15:58 UTC (permalink / raw)
Cc: Juanma Barranquero, Nick Roberts, emacs-devel
Lennart Borgman <lennart.borgman.073@student.lu.se> writes:
> David Kastrup wrote:
>> "Juanma Barranquero" <lekktu@gmail.com> writes:
>>
>>> On 11/19/06, Nick Roberts <nickrob@snap.net.nz> wrote:
>>>
>>>> I'm not telling people what to do, or demanding anything. I'm just
>>>> saying that I don't it is appropriate to delay things for further
>>>> improvements to emacsclient on Windows. If you're going to sum up,
>>>> at least do it accurately.
>>> Lennart is *proposing* changes that would allow emacsclient to
>>> automatically start Emacs if it is not running already.
>>
>> Could anybody summarize what is missing in order to make
>>
>> emacsclient --alternate-editor "emacs --eval '(server-start)'"
>>
>> work for this purpose? That seems simple enough, but I could be
>> likely missing some part of the picture.
>
>
> Perhaps I could answer ;-)
>
> What is missing is something that allows you to just use
>
> emacsclient -n myfile
>
> without doing any setup whatever, without having to start Emacs
> before. It should in my opinion work right out of the box.
Are there really typical use cases which require -n? If so, is there
a need for them to wait for --alternate-editor?
> The reason? The threshold is already high to start to use Emacs. For
> new users it is very important to be able to start immediately right
> after installing Emacs. Otherwise a lot of potential user might
> never start using Emacs.
What is the problem with the invocation I gave? The _technical_
problem? If a shorthand option for that invocation would be
desirable, it would be possible to implement this in about three lines
of code, so why is something different required?
> The possibility to do something like the line you propose should still
> be there, but with my patch you should be able to just use
>
> emacsclient --alternative-editor="whateveryoulike" myfile
>
> instead.
Why would that not work with the existing code? It did work up to
now, didn't it?
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-11-19 14:45 ` Pretest Lennart Borgman
2006-11-19 15:58 ` Pretest David Kastrup
@ 2006-11-19 17:54 ` Jason Rumney
2006-11-19 19:14 ` Pretest Lennart Borgman
2006-11-19 19:50 ` Pretest Jason Rumney
1 sibling, 2 replies; 172+ messages in thread
From: Jason Rumney @ 2006-11-19 17:54 UTC (permalink / raw)
Cc: Juanma Barranquero, Nick Roberts, emacs-devel
Lennart Borgman wrote:
>
> - system() -- needs a helper program to avoid wait
>
In the most important use case, we don't want to wait. Everything else
is handled by ALTERNATE_EDITOR already.
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-11-19 15:58 ` Pretest David Kastrup
@ 2006-11-19 19:13 ` Lennart Borgman
2006-11-19 19:27 ` Pretest David Kastrup
0 siblings, 1 reply; 172+ messages in thread
From: Lennart Borgman @ 2006-11-19 19:13 UTC (permalink / raw)
Cc: Juanma Barranquero, Nick Roberts, emacs-devel
David Kastrup wrote:
> Lennart Borgman <lennart.borgman.073@student.lu.se> writes:
>> What is missing is something that allows you to just use
>>
>> emacsclient -n myfile
>>
>> without doing any setup whatever, without having to start Emacs
>> before. It should in my opinion work right out of the box.
>
> Are there really typical use cases which require -n? If so, is there
> a need for them to wait for --alternate-editor?
Sorry, I did not mean that
emacsclient myfile
is not equally important. There are of course many typical use cases
both with and without -n.
>> The reason? The threshold is already high to start to use Emacs. For
>> new users it is very important to be able to start immediately right
>> after installing Emacs. Otherwise a lot of potential user might
>> never start using Emacs.
>
> What is the problem with the invocation I gave? The _technical_
> problem? If a shorthand option for that invocation would be
> desirable, it would be possible to implement this in about three lines
> of code, so why is something different required?
Are you saying that you could implement this in a general way so that a
new user right after installation can just type something like
emacsclient myfile
or
emacsclient -n myfile
in just three lines of code? I did actually not add many lines to do
this (most was restructuring of existing code), but I added quite a bit
more than tree lines.
>> The possibility to do something like the line you propose should still
>> be there, but with my patch you should be able to just use
>>
>> emacsclient --alternative-editor="whateveryoulike" myfile
>>
>> instead.
>
> Why would that not work with the existing code? It did work up to
> now, didn't it?
I think Juanma gave you a reason before. It seems impossible to
implement the wait this way. (And I am sure you can see the details
yourself.)
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-11-19 17:54 ` Pretest Jason Rumney
@ 2006-11-19 19:14 ` Lennart Borgman
2006-11-19 19:50 ` Pretest Jason Rumney
1 sibling, 0 replies; 172+ messages in thread
From: Lennart Borgman @ 2006-11-19 19:14 UTC (permalink / raw)
Cc: Juanma Barranquero, Nick Roberts, emacs-devel
Jason Rumney wrote:
> Lennart Borgman wrote:
>>
>> - system() -- needs a helper program to avoid wait
>>
> In the most important use case, we don't want to wait. Everything else
> is handled by ALTERNATE_EDITOR already.
>
Yes, that is true. But we do have a wait flag (-n) for a reason.
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-11-19 19:13 ` Pretest Lennart Borgman
@ 2006-11-19 19:27 ` David Kastrup
2006-11-20 1:15 ` Pretest Stefan Monnier
0 siblings, 1 reply; 172+ messages in thread
From: David Kastrup @ 2006-11-19 19:27 UTC (permalink / raw)
Cc: Juanma Barranquero, Nick Roberts, emacs-devel
Lennart Borgman <lennart.borgman.073@student.lu.se> writes:
> David Kastrup wrote:
>> Lennart Borgman <lennart.borgman.073@student.lu.se> writes:
>>> What is missing is something that allows you to just use
>>>
>>> emacsclient -n myfile
>>>
>>> without doing any setup whatever, without having to start Emacs
>>> before. It should in my opinion work right out of the box.
>>
>> Are there really typical use cases which require -n? If so, is there
>> a need for them to wait for --alternate-editor?
>
>
> Sorry, I did not mean that
>
> emacsclient myfile
>
> is not equally important. There are of course many typical use cases
> both with and without -n.
>
>>> The reason? The threshold is already high to start to use Emacs. For
>>> new users it is very important to be able to start immediately right
>>> after installing Emacs. Otherwise a lot of potential user might
>>> never start using Emacs.
>>
>> What is the problem with the invocation I gave? The _technical_
>> problem? If a shorthand option for that invocation would be
>> desirable, it would be possible to implement this in about three lines
>> of code, so why is something different required?
>
>
> Are you saying that you could implement this in a general way so that
> a new user right after installation can just type something like
>
> emacsclient myfile
> or
> emacsclient -n myfile
>
> in just three lines of code? I did actually not add many lines to do
> this (most was restructuring of existing code), but I added quite a
> bit more than tree lines.
Again: what is the problem with
emacsclient -a 'emacs --eval (server-start)'
? If there is no problem with that, I don't see why implement a
shorthand option that does nothing but that would not do the trick.
>>> The possibility to do something like the line you propose should
>>> still be there, but with my patch you should be able to just use
>>>
>>> emacsclient --alternative-editor="whateveryoulike" myfile
>>>
>>> instead.
>>
>> Why would that not work with the existing code? It did work up to
>> now, didn't it?
>
> I think Juanma gave you a reason before.
I must be dense.
> It seems impossible to implement the wait this way. (And I am sure
> you can see the details yourself.)
Which wait?
Could you explain a use case where the invocation
emacsclient -a 'emacs --eval (server-start)'
would not work?
That was my question and I still don't see that it has been answered.
Maybe I am too stupid to get it.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-11-19 17:54 ` Pretest Jason Rumney
2006-11-19 19:14 ` Pretest Lennart Borgman
@ 2006-11-19 19:50 ` Jason Rumney
2006-11-19 20:48 ` Pretest David Kastrup
1 sibling, 1 reply; 172+ messages in thread
From: Jason Rumney @ 2006-11-19 19:50 UTC (permalink / raw)
Cc: Lennart Borgman, Nick Roberts, emacs-devel, Juanma Barranquero
Jason Rumney wrote:
> In the most important use case, we don't want to wait.
I meant we DO want to wait here.
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-11-18 22:14 Pretest Chong Yidong
2006-11-18 22:58 ` Pretest Lennart Borgman
2006-11-19 12:48 ` Pretest Richard Stallman
@ 2006-11-19 19:59 ` Eli Zaretskii
2 siblings, 0 replies; 172+ messages in thread
From: Eli Zaretskii @ 2006-11-19 19:59 UTC (permalink / raw)
Cc: emacs-devel
> From: Chong Yidong <cyd@stupidchicken.com>
> Date: Sat, 18 Nov 2006 17:14:48 -0500
>
> I've rolled a new pretest tarball, which is available at
>
> ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-22.0.91.tar.gz
Thanks. This builds okay on Windows XP with the MinGW port of GCC.
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-11-19 12:48 ` Pretest Richard Stallman
@ 2006-11-19 20:08 ` Eli Zaretskii
2006-11-19 21:50 ` Pretest Reiner Steib
1 sibling, 0 replies; 172+ messages in thread
From: Eli Zaretskii @ 2006-11-19 20:08 UTC (permalink / raw)
Cc: cyd, emacs-devel
> From: Richard Stallman <rms@gnu.org>
> Date: Sun, 19 Nov 2006 07:48:44 -0500
> Cc: emacs-devel@gnu.org
>
> I think someone suggested using Reply-to to avoid encouraging people
> to send all their replies to the emacs-pretesters list. That would
> do the job if someone were doing "reply to sender", but if someone
> does "reply all" it will still go to the list.
>
> Would Mail-followup-to do the job?
I guess it depends on the MUA. We could use both these headers, just
to be sure.
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-11-19 19:50 ` Pretest Jason Rumney
@ 2006-11-19 20:48 ` David Kastrup
2006-11-19 21:33 ` Pretest Lennart Borgman
` (3 more replies)
0 siblings, 4 replies; 172+ messages in thread
From: David Kastrup @ 2006-11-19 20:48 UTC (permalink / raw)
Cc: Juanma Barranquero, Lennart Borgman, Nick Roberts, emacs-devel
Jason Rumney <jasonr@gnu.org> writes:
> Jason Rumney wrote:
>> In the most important use case, we don't want to wait.
> I meant we DO want to wait here.
Why? The most important case would be a file association or GUI
button I would guess, and there waiting or not waiting does not tend
to make a difference, does it?
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-11-19 20:48 ` Pretest David Kastrup
@ 2006-11-19 21:33 ` Lennart Borgman
2006-11-19 21:33 ` Pretest Jason Rumney
` (2 subsequent siblings)
3 siblings, 0 replies; 172+ messages in thread
From: Lennart Borgman @ 2006-11-19 21:33 UTC (permalink / raw)
Cc: Juanma Barranquero, Nick Roberts, emacs-devel, Jason Rumney
David Kastrup wrote:
> Jason Rumney <jasonr@gnu.org> writes:
>
>> Jason Rumney wrote:
>>> In the most important use case, we don't want to wait.
>> I meant we DO want to wait here.
>
> Why? The most important case would be a file association or GUI
> button I would guess, and there waiting or not waiting does not tend
> to make a difference, does it?
I got complaints before about processes hanging around when gnuclient
was waiting on w32. (It was actually quite comical since each gnuclient
had its own command window (console window) on w32. I did not notice
since I always had quite a lot of windows.)
That was actually why I started looking into the problem with waiting
and non-waiting clients and automatical start of Emacs ;-)
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-11-19 20:48 ` Pretest David Kastrup
2006-11-19 21:33 ` Pretest Lennart Borgman
@ 2006-11-19 21:33 ` Jason Rumney
2006-11-19 21:49 ` Pretest David Kastrup
2006-11-19 21:34 ` Pretest Lennart Borgman
2006-11-19 21:38 ` Pretest Lennart Borgman
3 siblings, 1 reply; 172+ messages in thread
From: Jason Rumney @ 2006-11-19 21:33 UTC (permalink / raw)
Cc: Juanma Barranquero, Lennart Borgman, Nick Roberts, emacs-devel
David Kastrup wrote:
> Jason Rumney <jasonr@gnu.org> writes:
>
>>> In the most important use case, we DO want to wait.
>>>
>
> Why?
Because most programs that launch an editor as a subprocess need to know
when editing has finished.
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-11-19 20:48 ` Pretest David Kastrup
2006-11-19 21:33 ` Pretest Lennart Borgman
2006-11-19 21:33 ` Pretest Jason Rumney
@ 2006-11-19 21:34 ` Lennart Borgman
2006-11-19 21:38 ` Pretest Lennart Borgman
3 siblings, 0 replies; 172+ messages in thread
From: Lennart Borgman @ 2006-11-19 21:34 UTC (permalink / raw)
Cc: Juanma Barranquero, Nick Roberts, emacs-devel, Jason Rumney
David Kastrup wrote:
> Jason Rumney <jasonr@gnu.org> writes:
>
>> Jason Rumney wrote:
>>> In the most important use case, we don't want to wait.
>> I meant we DO want to wait here.
>
> Why? The most important case would be a file association or GUI
> button I would guess, and there waiting or not waiting does not tend
> to make a difference, does it?
I got complaints before about processes hanging around when gnuclient
was waiting on w32. (It was actually quite comical since each gnuclient
had its own command window (console window) on w32. I did not notice
since I always had quite a lot of windows.)
That was actually why I started looking into the problem with waiting
and non-waiting clients and automatical start of Emacs ;-)
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-11-19 20:48 ` Pretest David Kastrup
` (2 preceding siblings ...)
2006-11-19 21:34 ` Pretest Lennart Borgman
@ 2006-11-19 21:38 ` Lennart Borgman
3 siblings, 0 replies; 172+ messages in thread
From: Lennart Borgman @ 2006-11-19 21:38 UTC (permalink / raw)
Cc: Juanma Barranquero, Nick Roberts, emacs-devel, Jason Rumney
David Kastrup wrote:
> Jason Rumney <jasonr@gnu.org> writes:
>
>> Jason Rumney wrote:
>>> In the most important use case, we don't want to wait.
>> I meant we DO want to wait here.
>
> Why? The most important case would be a file association or GUI
> button I would guess, and there waiting or not waiting does not tend
> to make a difference, does it?
I got complaints before about processes hanging around when gnuclient
was waiting on w32. (It was actually quite comical since each gnuclient
had its own command window (console window) on w32. I did not notice
since I always had quite a lot of windows.)
That was actually why I started looking into the problem with waiting
and non-waiting clients and automatical start of Emacs ;-)
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-11-19 21:33 ` Pretest Jason Rumney
@ 2006-11-19 21:49 ` David Kastrup
2006-11-19 22:04 ` Pretest Jason Rumney
` (2 more replies)
0 siblings, 3 replies; 172+ messages in thread
From: David Kastrup @ 2006-11-19 21:49 UTC (permalink / raw)
Cc: Juanma Barranquero, Lennart Borgman, Nick Roberts, emacs-devel
Jason Rumney <jasonr@gnu.org> writes:
> David Kastrup wrote:
>> Jason Rumney <jasonr@gnu.org> writes:
>>
>>>> In the most important use case, we DO want to wait.
>>>>
>>
>> Why?
>
> Because most programs that launch an editor as a subprocess need to
> know when editing has finished.
So the "most important use case" according to you is basically a
command line call, not a GUI call. That was not obvious to me. And
we are talking about an emacsclient connection on Windows. When Emacs
is already running, emacsclient will connect to Emacs and block while
Emacs in its existing frame is working on a file. When one is
finished working this file, Emacs would then get emacsclient to exit
by telling it it quit.
In order to mimic this behavior when Emacs is not already running, you
want to have it started in a detached manner, then have emacsclient
attach to it once its server is running, and have it exit when the
Emacs server tells it to.
Wouldn't it be saner if emacsclient just started Emacs (probably with
a specific command line option), and when Emacs was finished with
editing the respective buffer, it would detach itself from emacsclient
which would then exit?
That would obliterate all the waiting for server-start issues. It
would just mean that server-buffers initiated from the command line
instead of emacsclient would exit by detaching themselves from the
controlling terminal instead of talking to emacsclient on a socket.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-11-19 12:48 ` Pretest Richard Stallman
2006-11-19 20:08 ` Pretest Eli Zaretskii
@ 2006-11-19 21:50 ` Reiner Steib
2006-11-20 12:59 ` Pretest Richard Stallman
1 sibling, 1 reply; 172+ messages in thread
From: Reiner Steib @ 2006-11-19 21:50 UTC (permalink / raw)
Cc: Chong Yidong, emacs-devel
On Sun, Nov 19 2006, Richard Stallman wrote:
> I think someone suggested using Reply-to to avoid encouraging people
> to send all their replies to the emacs-pretesters list. That would
> do the job if someone were doing "reply to sender", but if someone
> does "reply all" it will still go to the list.
>
> Would Mail-followup-to do the job?
Yes, that's the purpose of Mail-Followup-To. But only some MUAs
(Gnus, MH-E, mutt, ...) support it. But adding it Mail-Followup-To
won't hurt. Additionally I'd suggest to say it in the message body.
Bye, Reiner.
--
,,,
(o o)
---ooO-(_)-Ooo--- | PGP key available | http://rsteib.home.pages.de/
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-11-19 21:49 ` Pretest David Kastrup
@ 2006-11-19 22:04 ` Jason Rumney
2006-11-19 22:06 ` Pretest Lennart Borgman
2006-11-20 1:20 ` Pretest Stefan Monnier
2 siblings, 0 replies; 172+ messages in thread
From: Jason Rumney @ 2006-11-19 22:04 UTC (permalink / raw)
Cc: Juanma Barranquero, Lennart Borgman, Nick Roberts, emacs-devel
David Kastrup wrote:
> Jason Rumney <jasonr@gnu.org> writes:
>
>
>> Because most programs that launch an editor as a subprocess need to
>> know when editing has finished.
>>
>
> So the "most important use case" according to you is basically a
> command line call, not a GUI call.
I'm not sure where this distinction between "GUI calls" and "command
line calls" comes from. I'm talking about ANY program that wants to use
an external editor here. They either require emacsclient to wait until
editing is done, or they don't care. So it worries me that the focus is
on the --no-wait case for this, since that is already handled, and isn't
a lot of use except for command-line use where the user wants their
interactive shell back immediately.
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-11-19 21:49 ` Pretest David Kastrup
2006-11-19 22:04 ` Pretest Jason Rumney
@ 2006-11-19 22:06 ` Lennart Borgman
2006-11-19 22:44 ` Pretest David Kastrup
2006-11-20 1:20 ` Pretest Stefan Monnier
2 siblings, 1 reply; 172+ messages in thread
From: Lennart Borgman @ 2006-11-19 22:06 UTC (permalink / raw)
Cc: Juanma Barranquero, Nick Roberts, emacs-devel, Jason Rumney
David Kastrup wrote:
> Jason Rumney <jasonr@gnu.org> writes:
>
>> David Kastrup wrote:
>>> Jason Rumney <jasonr@gnu.org> writes:
>>>
>>>>> In the most important use case, we DO want to wait.
>>>>>
>>> Why?
>> Because most programs that launch an editor as a subprocess need to
>> know when editing has finished.
>
> So the "most important use case" according to you is basically a
> command line call, not a GUI call. That was not obvious to me. And
> we are talking about an emacsclient connection on Windows. When Emacs
> is already running, emacsclient will connect to Emacs and block while
> Emacs in its existing frame is working on a file. When one is
> finished working this file, Emacs would then get emacsclient to exit
> by telling it it quit.
>
> In order to mimic this behavior when Emacs is not already running, you
> want to have it started in a detached manner, then have emacsclient
> attach to it once its server is running, and have it exit when the
> Emacs server tells it to.
>
> Wouldn't it be saner if emacsclient just started Emacs (probably with
> a specific command line option), and when Emacs was finished with
> editing the respective buffer, it would detach itself from emacsclient
> which would then exit?
>
> That would obliterate all the waiting for server-start issues. It
> would just mean that server-buffers initiated from the command line
> instead of emacsclient would exit by detaching themselves from the
> controlling terminal instead of talking to emacsclient on a socket.
I am trying to understand what you mean here, but I fail. Is this
perhaps something that can be done with X Windows?
And what issues do you mean when you write "waiting for server-start
issues"? Is it perhaps those I hope I have solved in my code?
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-11-19 22:06 ` Pretest Lennart Borgman
@ 2006-11-19 22:44 ` David Kastrup
2006-11-19 23:02 ` Pretest Lennart Borgman
0 siblings, 1 reply; 172+ messages in thread
From: David Kastrup @ 2006-11-19 22:44 UTC (permalink / raw)
Cc: Juanma Barranquero, Nick Roberts, emacs-devel, Jason Rumney
Lennart Borgman <lennart.borgman.073@student.lu.se> writes:
> David Kastrup wrote:
>> Jason Rumney <jasonr@gnu.org> writes:
>>
>>> David Kastrup wrote:
>>>> Jason Rumney <jasonr@gnu.org> writes:
>>>>
>>>>>> In the most important use case, we DO want to wait.
>>>>>>
>>>> Why?
>>> Because most programs that launch an editor as a subprocess need to
>>> know when editing has finished.
>>
>> So the "most important use case" according to you is basically a
>> command line call, not a GUI call. That was not obvious to me.
>> And we are talking about an emacsclient connection on Windows.
>> When Emacs is already running, emacsclient will connect to Emacs
>> and block while Emacs in its existing frame is working on a file.
>> When one is finished working this file, Emacs would then get
>> emacsclient to exit by telling it it quit.
>>
>> In order to mimic this behavior when Emacs is not already running,
>> you want to have it started in a detached manner, then have
>> emacsclient attach to it once its server is running, and have it
>> exit when the Emacs server tells it to.
>>
>> Wouldn't it be saner if emacsclient just started Emacs (probably
>> with a specific command line option), and when Emacs was finished
>> with editing the respective buffer, it would detach itself from
>> emacsclient which would then exit?
>>
>> That would obliterate all the waiting for server-start issues. It
>> would just mean that server-buffers initiated from the command line
>> instead of emacsclient would exit by detaching themselves from the
>> controlling terminal instead of talking to emacsclient on a socket.
>
>
> I am trying to understand what you mean here, but I fail. Is this
> perhaps something that can be done with X Windows?
Nothing to do with X11.
> And what issues do you mean when you write "waiting for server-start
> issues"? Is it perhaps those I hope I have solved in my code?
You want to start an Emacs if it is not present, detach it so that its
life time does not depend on emacsserver, wait until it has started a
server (if it does so in the first place), then connect to it, tell it
what buffer to edit, and ask it to tell you when this is done.
I am proposing that instead one uses something like
emacsclient -a "emacs -delayed-detach"
where emacsclient does not actually have a clue that it has started an
Emacs, and does not try talking to it. Instead it waits until emacs
dies. What emacs does instead would, in Unixspeak, be to fork. The
child would then detach itself from the controlling terminal, take the
command line options and start an almost normal Emacs life. When the
user executed a "server-done", however, the child would kill its
parent which would then exit.
Now under Windows this forking stuff does not work IIRC. Once one
starts a big process like Emacs, it is not cheap to start another copy
from inside.
So instead of "emacs -delayed-detach" one would rather start something
like "emacsproxy" with the command line arguments.
emacsproxy would then start the proper Emacs process with its command
line, and the proper Emacs process would, upon getting "server-done"
executed by the user, kill the emacsproxy process.
So the invocation for emacsclient would be something like
emacsclient -a emacsproxy
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-11-19 22:44 ` Pretest David Kastrup
@ 2006-11-19 23:02 ` Lennart Borgman
2006-11-19 23:31 ` Pretest David Kastrup
0 siblings, 1 reply; 172+ messages in thread
From: Lennart Borgman @ 2006-11-19 23:02 UTC (permalink / raw)
Cc: Juanma Barranquero, Nick Roberts, emacs-devel, Jason Rumney
David Kastrup wrote:
> Lennart Borgman <lennart.borgman.073@student.lu.se> writes:
>
>> David Kastrup wrote:
>>> Jason Rumney <jasonr@gnu.org> writes:
>>>
>>>> David Kastrup wrote:
>>>>> Jason Rumney <jasonr@gnu.org> writes:
>>>>>
>>>>>>> In the most important use case, we DO want to wait.
>>>>>>>
>>>>> Why?
>>>> Because most programs that launch an editor as a subprocess need to
>>>> know when editing has finished.
>>> So the "most important use case" according to you is basically a
>>> command line call, not a GUI call. That was not obvious to me.
>>> And we are talking about an emacsclient connection on Windows.
>>> When Emacs is already running, emacsclient will connect to Emacs
>>> and block while Emacs in its existing frame is working on a file.
>>> When one is finished working this file, Emacs would then get
>>> emacsclient to exit by telling it it quit.
>>>
>>> In order to mimic this behavior when Emacs is not already running,
>>> you want to have it started in a detached manner, then have
>>> emacsclient attach to it once its server is running, and have it
>>> exit when the Emacs server tells it to.
>>>
>>> Wouldn't it be saner if emacsclient just started Emacs (probably
>>> with a specific command line option), and when Emacs was finished
>>> with editing the respective buffer, it would detach itself from
>>> emacsclient which would then exit?
>>>
>>> That would obliterate all the waiting for server-start issues. It
>>> would just mean that server-buffers initiated from the command line
>>> instead of emacsclient would exit by detaching themselves from the
>>> controlling terminal instead of talking to emacsclient on a socket.
>>
>> I am trying to understand what you mean here, but I fail. Is this
>> perhaps something that can be done with X Windows?
>
> Nothing to do with X11.
Thanks.
>> And what issues do you mean when you write "waiting for server-start
>> issues"? Is it perhaps those I hope I have solved in my code?
>
> You want to start an Emacs if it is not present, detach it so that its
> life time does not depend on emacsserver, wait until it has started a
> server (if it does so in the first place), then connect to it, tell it
> what buffer to edit, and ask it to tell you when this is done.
>
> I am proposing that instead one uses something like
>
> emacsclient -a "emacs -delayed-detach"
>
> where emacsclient does not actually have a clue that it has started an
> Emacs, and does not try talking to it. Instead it waits until emacs
> dies. What emacs does instead would, in Unixspeak, be to fork. The
> child would then detach itself from the controlling terminal, take the
> command line options and start an almost normal Emacs life. When the
> user executed a "server-done", however, the child would kill its
> parent which would then exit.
But would not the fork used in this way mean that we during "waited
editing" has two emacs processes (or more)? Would not that defeat some
of the benefits of emacs server?
> Now under Windows this forking stuff does not work IIRC. Once one
> starts a big process like Emacs, it is not cheap to start another copy
> from inside.
>
> So instead of "emacs -delayed-detach" one would rather start something
> like "emacsproxy" with the command line arguments.
>
> emacsproxy would then start the proper Emacs process with its command
> line, and the proper Emacs process would, upon getting "server-done"
> executed by the user, kill the emacsproxy process.
>
> So the invocation for emacsclient would be something like
>
> emacsclient -a emacsproxy
Thanks, I believe I understand this part, but it is quite a bit more
complicated than what I actually have implemented.
For what reason do you want to avoid the wait for the server process to
start the way I have implemented it? Doing it that way means that
emacsclient always communicates with emacs server in the same way and I
think that is very important from a code complexity point of view.
One drawback I can see is that you can not know for sure if the server
ever starts. Therefore I have added a simple timeout for how long
emacsclient waits for emacs server to start.
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-11-19 23:02 ` Pretest Lennart Borgman
@ 2006-11-19 23:31 ` David Kastrup
2006-11-20 0:59 ` Pretest Lennart Borgman
0 siblings, 1 reply; 172+ messages in thread
From: David Kastrup @ 2006-11-19 23:31 UTC (permalink / raw)
Cc: Juanma Barranquero, Nick Roberts, emacs-devel, Jason Rumney
Lennart Borgman <lennart.borgman.073@student.lu.se> writes:
> David Kastrup wrote:
>> You want to start an Emacs if it is not present, detach it so that
>> its life time does not depend on emacsserver, wait until it has
>> started a server (if it does so in the first place), then connect
>> to it, tell it what buffer to edit, and ask it to tell you when
>> this is done.
>>
>> I am proposing that instead one uses something like
>>
>> emacsclient -a "emacs -delayed-detach"
>>
>> where emacsclient does not actually have a clue that it has started
>> an Emacs, and does not try talking to it. Instead it waits until
>> emacs dies. What emacs does instead would, in Unixspeak, be to
>> fork. The child would then detach itself from the controlling
>> terminal, take the command line options and start an almost normal
>> Emacs life. When the user executed a "server-done", however, the
>> child would kill its parent which would then exit.
>
> But would not the fork used in this way mean that we during "waited
> editing" has two emacs processes (or more)? Would not that defeat
> some of the benefits of emacs server?
In Unix, fork is cheap. The processes share the same code, and the
data starts out shared (the MMU sets it to read-only, and only when
one of the processes writes to it, a copy is created on which it then
works). If the fork is done early in the life time of the process and
one of the forked processes touches only small amounts of data (which
would be the case here), the cost is negligible. Similarly if after
the fork one of the processes does nothing much except change programs
by virtue of an exec call.
I am aware that Windows does not have fork with similar semantics,
which is why I then made a different proposal:
>> Now under Windows this forking stuff does not work IIRC. Once one
>> starts a big process like Emacs, it is not cheap to start another copy
>> from inside.
>>
>> So instead of "emacs -delayed-detach" one would rather start something
>> like "emacsproxy" with the command line arguments.
>>
>> emacsproxy would then start the proper Emacs process with its command
>> line, and the proper Emacs process would, upon getting "server-done"
>> executed by the user, kill the emacsproxy process.
>>
>> So the invocation for emacsclient would be something like
>>
>> emacsclient -a emacsproxy
>
> Thanks, I believe I understand this part, but it is quite a bit more
> complicated than what I actually have implemented.
It has the advantage that it does not need to wait around, does not
need to rely on "server-start" getting fired up eventually and so on.
It bypasses the complete emacsserver business, and thus would be a
_reliable_ way to start an Emacs that can stay around even when the
socket stuff fails to work for some reason (permissions, file names,
whatever).
In addition, it would provide a separate "start Emacs, and simulate
finishing it when the user wants so" command which could conceivably
be useful in situations outside of the emacsclient/emacsserver
setting.
> For what reason do you want to avoid the wait for the server process
> to start the way I have implemented it?
Because it is not reliable. It depends on actions in the started
Emacs that are not under the control of emacsclient, and it requires a
separate mechanism not transparent to the user apart from
--alternate-editor.
> Doing it that way means that emacsclient always communicates with
> emacs server in the same way and I think that is very important from
> a code complexity point of view.
>From code complexity, emacsclient would just pass its options on to
the alternate editor, whether that is called emacsproxy or vi.
> One drawback I can see is that you can not know for sure if the
> server ever starts. Therefore I have added a simple timeout for how
> long emacsclient waits for emacs server to start.
I'd prefer the approach where emacsclient does not depend on Emacs
server to start.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-11-19 23:31 ` Pretest David Kastrup
@ 2006-11-20 0:59 ` Lennart Borgman
2006-11-20 1:20 ` Pretest David Kastrup
0 siblings, 1 reply; 172+ messages in thread
From: Lennart Borgman @ 2006-11-20 0:59 UTC (permalink / raw)
Cc: Juanma Barranquero, Nick Roberts, Jason Rumney, emacs-devel
David Kastrup wrote:
> In Unix, fork is cheap. The processes share the same code, and the
...
> I am aware that Windows does not have fork with similar semantics,
> which is why I then made a different proposal:
Thanks. I did actually misunderstand you quite a bit before and was
going to correct myself before I read this. We are using different language.
>> For what reason do you want to avoid the wait for the server process
>> to start the way I have implemented it?
>
> Because it is not reliable. It depends on actions in the started
> Emacs that are not under the control of emacsclient, and it requires a
> separate mechanism not transparent to the user apart from
> --alternate-editor.
You are right.
>> Doing it that way means that emacsclient always communicates with
>> emacs server in the same way and I think that is very important from
>> a code complexity point of view.
>
>>From code complexity, emacsclient would just pass its options on to
> the alternate editor, whether that is called emacsproxy or vi.
>
>> One drawback I can see is that you can not know for sure if the
>> server ever starts. Therefore I have added a simple timeout for how
>> long emacsclient waits for emacs server to start.
>
> I'd prefer the approach where emacsclient does not depend on Emacs
> server to start.
With a little twist your suggestion would be very similar to mine. The
main part of your suggestion as I see it is that emacsclient wait on an
intermediate process. This has the advantage that emacs could
communicate with it and tell emacsclient about errors. That is good.
Something like this would have the benefits of both yours and my suggestion:
1) If emacsclient could not contact emacs server then it create the
intermediate process. This then starts emacs and tells emacs to start
emacs server with the required arguments.
2) Emacsclient then wait for the intermediate process to disappear.
After that it checks for errors.
3) If there are errors then it tries to connect to the server again.
This is very similar to my current approach but better I believe. My
approach looks like this:
1) If emacsclient can not contact emacs server then it starts emacs and
tells emacs to start emacs server with the required arguments.
2) Emacsclient then loops and tries to connect to the server again. If
it takes too long then emacsclient assumes there is an error. If it can
connect that step is the same as 3 above.
I think this would be better. From a user perspective the main differenc
is better error handling. However it requires some changes to the emacs
executable and I do not believe it should be implemented now.
My proposal does not require any changes to emacs executable. And the
code is ready for testing now (except for some details I have asked for
comments on off the list, I am waiting for answers). However I would
like to have it tested here by people on emacs devel list before going
further.
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-11-19 19:27 ` Pretest David Kastrup
@ 2006-11-20 1:15 ` Stefan Monnier
0 siblings, 0 replies; 172+ messages in thread
From: Stefan Monnier @ 2006-11-20 1:15 UTC (permalink / raw)
Cc: Lennart Borgman, Nick Roberts, emacs-devel, Juanma Barranquero
> Again: what is the problem with
> emacsclient -a 'emacs --eval (server-start)'
> ?
Depends what you intend this to solve. What they want is to be able to say
"emacsclient <maybesomeoptionshere> <file>" and it should always work the
same way, whether Emacs was already started or not.
Your above invocation has no <file>, so it doesn't directly solve
their problem.
If you intended something like
emacsclient -a 'emacs --eval (server-start)' <file>
then it suffers from the problem that this command will only exit after the
Emacs server exits, rather than after you finish editing <file>.
So instead they intend to do something like
emacsclient -a 'emacs --eval (server-start) & emacsclient' <file>
but then they need to deal with the fact that the server is only accessible
after some amount of time, so the emacsclient after the "&" needs to be able
to deal with temporary connection failures.
Stefan
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-11-20 0:59 ` Pretest Lennart Borgman
@ 2006-11-20 1:20 ` David Kastrup
[not found] ` <45616414.2080802@student.lu.se>
0 siblings, 1 reply; 172+ messages in thread
From: David Kastrup @ 2006-11-20 1:20 UTC (permalink / raw)
Cc: Juanma Barranquero, Nick Roberts, Jason Rumney, emacs-devel
Lennart Borgman <lennart.borgman.073@student.lu.se> writes:
> David Kastrup wrote:
>
>> I'd prefer the approach where emacsclient does not depend on Emacs
>> server to start.
>
> With a little twist your suggestion would be very similar to mine.
Uh, you twist my proposal and then complain about the consequences of
the twist...
> The main part of your suggestion as I see it is that emacsclient
> wait on an intermediate process. This has the advantage that emacs
> could communicate with it and tell emacsclient about errors.
Uh no, it doesn't. The whole point was that emacsproxy behaves just
like a blackbox that can be used instead of --alternate-editor.
> That is good. Something like this would have the benefits of both
> yours and my suggestion:
>
> 1) If emacsclient could not contact emacs server then it create the
> intermediate process. This then starts emacs and tells emacs to
> start emacs server with the required arguments.
My proposal was all about _not_ needing to start Emacs server in the
first place. Instead, Emacs is set up such that server-quit will
_not_ attempt talking to some emacsclient, but will rather kill the
emacsproxy it was started from.
> 2) Emacsclient then wait for the intermediate process to
> disappear. After that it checks for errors.
My proposal was all about emacsclient starting the "emacsproxy" like
an editor, waiting for it to finish, and then considering the file
edited.
> 3) If there are errors then it tries to connect to the server again.
It does not need to connect to the server "again" since it never
connected to the server anyhow.
> However it requires some changes to the emacs executable and I do
> not believe it should be implemented now.
Hm. It requires emacsproxy to call Emacs with something like
--eval '(setq server-proxy-process 54321)'
or probably something like
-f server-proxy-setup 54321
and server-quit to do something like
(signal-process server-proxy-process 'INT)
in an appropriate place.
That's not really "requiring changes to the Emacs executable" in my
book.
There is one utterly unrelated problem I see here: I don't see how
`signal-process' could work reliably on 32bit systems with 32bit
process ids.
Similarly, how would `process-id' work in that case?
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-11-19 21:49 ` Pretest David Kastrup
2006-11-19 22:04 ` Pretest Jason Rumney
2006-11-19 22:06 ` Pretest Lennart Borgman
@ 2006-11-20 1:20 ` Stefan Monnier
2 siblings, 0 replies; 172+ messages in thread
From: Stefan Monnier @ 2006-11-20 1:20 UTC (permalink / raw)
Cc: Juanma Barranquero, Nick Roberts, emacs-devel, Lennart Borgman,
Jason Rumney
> So the "most important use case" according to you is basically a command
> line call, not a GUI call. That was not obvious to me. And we are
> talking about an emacsclient connection on Windows.
AFAIK this has nothing to do with w32-vs-theworld. The same issue
exists everywhere.
> Wouldn't it be saner if emacsclient just started Emacs (probably with
> a specific command line option), and when Emacs was finished with
> editing the respective buffer, it would detach itself from emacsclient
> which would then exit?
Sure. Patch welcome. Maybe you can find a neat wait to do the "detach"
part, but off-the-top-of-my-head I can't think of a simple way to do it.
Stefan
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-11-19 10:18 ` Pretest David Kastrup
2006-11-19 11:44 ` Pretest Nick Roberts
@ 2006-11-20 1:37 ` Richard Stallman
2006-11-20 3:00 ` Pretest Stefan Monnier
2006-11-20 9:01 ` Pretest Juanma Barranquero
1 sibling, 2 replies; 172+ messages in thread
From: Richard Stallman @ 2006-11-20 1:37 UTC (permalink / raw)
Cc: lennart.borgman.073, nickrob, cyd, emacs-devel
It seems like we have completely different recollections of events.
As far as I remember, Richard oked getting emacsclient to work on
Windows even after the first pretest (where emacsclient was not yet a
part of Emacs).
These changes were installed without properly asking me, and they
should not have been. However, later I was told they had been made to
work correctly, and decided it was ok to leave them installed.
Are there any problems with the _current_ code?
If so, what are they?
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-11-20 1:37 ` Pretest Richard Stallman
@ 2006-11-20 3:00 ` Stefan Monnier
2006-11-20 9:01 ` Pretest Juanma Barranquero
1 sibling, 0 replies; 172+ messages in thread
From: Stefan Monnier @ 2006-11-20 3:00 UTC (permalink / raw)
Cc: lennart.borgman.073, nickrob, cyd, emacs-devel
> It seems like we have completely different recollections of events.
> As far as I remember, Richard oked getting emacsclient to work on
> Windows even after the first pretest (where emacsclient was not yet a
> part of Emacs).
> These changes were installed without properly asking me, and they
> should not have been. However, later I was told they had been made to
> work correctly, and decided it was ok to leave them installed.
> Are there any problems with the _current_ code?
> If so, what are they?
No, there is no known problem with the current code.
What is being discussed is work on some additional feature which some people
would want to include, but I don't think it's ever been decided whether that
should be accepted for Emacs-22 or not.
Stefan
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-11-20 1:37 ` Pretest Richard Stallman
2006-11-20 3:00 ` Pretest Stefan Monnier
@ 2006-11-20 9:01 ` Juanma Barranquero
2006-11-20 9:37 ` Pretest Jason Rumney
` (2 more replies)
1 sibling, 3 replies; 172+ messages in thread
From: Juanma Barranquero @ 2006-11-20 9:01 UTC (permalink / raw)
Cc: emacs-devel
On 11/20/06, Richard Stallman <rms@gnu.org> wrote:
> These changes were installed without properly asking me, and they
> should not have been.
As I demonstrated in a previous thread, I repeatedly asked on the
list. Excuse me for not knowing that some things should be asked by
private e-mail. Perhaps you could write down the exact procedures.
> Are there any problems with the _current_ code?
No. We're talking about extending functionality so emacsclient can
totally replace gnuclient/gnuserv.
/L/e/k/t/u
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-11-20 9:01 ` Pretest Juanma Barranquero
@ 2006-11-20 9:37 ` Jason Rumney
2006-11-20 10:06 ` Pretest Juanma Barranquero
2006-11-20 10:01 ` Pretest David Kastrup
2006-11-20 23:58 ` Pretest Richard Stallman
2 siblings, 1 reply; 172+ messages in thread
From: Jason Rumney @ 2006-11-20 9:37 UTC (permalink / raw)
Cc: rms, emacs-devel
Juanma Barranquero wrote:
> No. We're talking about extending functionality so emacsclient can
> totally replace gnuclient/gnuserv.
Can't it do that now, with --alternate-editor and emacsclientw.exe on
Windows?
The only thing left is fixing the edge case where "emacsclient
--alternate-editor emacs" exits immediately, which causes problems for
programs that use emacsclient as an external editor. AFAICT gnuclient
also has this same problem. IMHO this should wait until after release,
because there are significant changes needed, see David Kastrup's most
recent posts.
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
[not found] ` <45616414.2080802@student.lu.se>
@ 2006-11-20 9:55 ` David Kastrup
0 siblings, 0 replies; 172+ messages in thread
From: David Kastrup @ 2006-11-20 9:55 UTC (permalink / raw)
Cc: emacs-devel
Lennart Borgman <lennart.borgman.073@student.lu.se> writes:
> David Kastrup wrote:
>> Lennart Borgman <lennart.borgman.073@student.lu.se> writes:
>
> I am asking you off list not to clutter the list. I believe I still do
> not understand you.
I don't think it makes sense to take this off-list since we are
talking about how to implement something that affects all users, and
since there must be a consensus how to get there eventually. And if
my explanations are deficient, you are not the only person who should
get a better version of them.
So I am taking the liberty of including the list again.
>> My proposal was all about _not_ needing to start Emacs server in
>> the first place. Instead, Emacs is set up such that server-quit
>> will _not_ attempt talking to some emacsclient, but will rather
>> kill the emacsproxy it was started from.
>
> Maybe I understand now. But does not your proposal mean that you
> have several emacsen running if you are waiting for sever files or
> have emacs running as a server at the same time, or?
>
> Does it not also mean that for each file you want to edit this way
> emacs have to start itself and then run the init files?
Only if a user indeed does not have (server-start) in his .emacs file
or the communication fails.
If that is found dissatisfactory as a default, it would be possible to
let server-proxy-start (or whatever emacsproxy would cause its Emacs
copy to execute in order to inform it what process to kill on
server-done) also start the Emacs server by default. But it would be
something which would not concern the operation of the _currently_
executing emacsclient/emacsproxy/emacs trio. _This_ emacsclient has
already decided not to try the socket again and _replaced_ itself via
exec with emacsproxy as an alternative editor, and emacsproxy does not
talk via a socket, anyway, since its whole purpose is just to be an
Emacs replacement that exits in proxy when server-done is executed in
its Emacs, without going through the socket.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-11-20 9:01 ` Pretest Juanma Barranquero
2006-11-20 9:37 ` Pretest Jason Rumney
@ 2006-11-20 10:01 ` David Kastrup
2006-11-20 23:58 ` Pretest Richard Stallman
2 siblings, 0 replies; 172+ messages in thread
From: David Kastrup @ 2006-11-20 10:01 UTC (permalink / raw)
Cc: rms, emacs-devel
"Juanma Barranquero" <lekktu@gmail.com> writes:
> On 11/20/06, Richard Stallman <rms@gnu.org> wrote:
>
>> These changes were installed without properly asking me, and they
>> should not have been.
>
> As I demonstrated in a previous thread, I repeatedly asked on the
> list. Excuse me for not knowing that some things should be asked by
> private e-mail. Perhaps you could write down the exact procedures.
>
>> Are there any problems with the _current_ code?
>
> No. We're talking about extending functionality so emacsclient can
> totally replace gnuclient/gnuserv.
That is not possible without the multi-tty branch, anyway, since
gnuclient, called from a text console, will open a text mode tty in
it. emacsserver, in contrast, always lets Emacs open on the
console/tty/window where it was started.
What we are currently trying to do, if I understand correctly, is
rather making emacsclient something which will "do the right thing
(TM)" without the need of additional customization, regardless of
whether an Emacs session did or did not exist at the point of time
when emacsclient is called.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-11-20 9:37 ` Pretest Jason Rumney
@ 2006-11-20 10:06 ` Juanma Barranquero
2006-11-20 10:50 ` Pretest David Kastrup
0 siblings, 1 reply; 172+ messages in thread
From: Juanma Barranquero @ 2006-11-20 10:06 UTC (permalink / raw)
Cc: emacs-devel
On 11/20/06, Jason Rumney <jasonr@gnu.org> wrote:
> Can't it do that now, with --alternate-editor and emacsclientw.exe on Windows?
Most, except...
> The only thing left is fixing the edge case where "emacsclient
> --alternate-editor emacs" exits immediately, which causes problems for
> programs that use emacsclient as an external editor.
...this.
> AFAICT gnuclient also has this same problem.
There are quite a few gnuclient versions out there. The one from
Lennart's page does not present this problem.
> IMHO this should wait until after release,
> because there are significant changes needed, see David Kastrup's most
> recent posts.
In all truth, I took just a cursory look on David's "fix", but it
seemed a bit of handwaving to me, particularly (as Stefan as already
said) on the "detach" part, which is the biggest difficulty in
Lennart's work so far. So: patches welcome.
/L/e/k/t/u
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-11-20 10:06 ` Pretest Juanma Barranquero
@ 2006-11-20 10:50 ` David Kastrup
2006-11-20 10:58 ` Pretest Juanma Barranquero
0 siblings, 1 reply; 172+ messages in thread
From: David Kastrup @ 2006-11-20 10:50 UTC (permalink / raw)
Cc: emacs-devel, Jason Rumney
"Juanma Barranquero" <lekktu@gmail.com> writes:
> On 11/20/06, Jason Rumney <jasonr@gnu.org> wrote:
>
>> IMHO this should wait until after release, because there are
>> significant changes needed, see David Kastrup's most recent posts.
>
> In all truth, I took just a cursory look on David's "fix", but it
> seemed a bit of handwaving to me, particularly (as Stefan as already
> said) on the "detach" part, which is the biggest difficulty in
> Lennart's work so far. So: patches welcome.
Well, the "detach" stuff certainly had a bit of handwaving to it, but
I fleshed it out in later posts by proposing an additional
"emacsproxy" which would work without "fork" and similar niceties.
I do agree that while the approach that I fleshed out seems to me like
a more robust and transparent approach to the problem Lennart tries to
tackle, either approach would be a feature extension.
Lennart's would be easier to sneak in under the "we are in pretest, no
new features" reign, but personally I don't feel it is the most robust
way to tackle the problem, and it also would require updating manual
pages and documentation and stuff.
So my personal feeling is that for 22.1, we should bring emacsclient
under Windows merely up to what we already have under POSIX systems,
and leave the design and testing of further improvements to 23.1, in
particular since folding multi-tty support will make emacsclient a
whole different game, anyway, since it will then presumably be able to
open an editor in the current text tty, too (emacsclient -nw ...).
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-11-20 10:50 ` Pretest David Kastrup
@ 2006-11-20 10:58 ` Juanma Barranquero
2006-11-20 15:30 ` Pretest Stefan Monnier
0 siblings, 1 reply; 172+ messages in thread
From: Juanma Barranquero @ 2006-11-20 10:58 UTC (permalink / raw)
Cc: emacs-devel
On 11/20/06, David Kastrup <dak@gnu.org> wrote:
> Well, the "detach" stuff certainly had a bit of handwaving to it, but
> I fleshed it out in later posts by proposing an additional
> "emacsproxy" which would work without "fork" and similar niceties.
Yes, you're right.
> Lennart's would be easier to sneak in under the "we are in pretest, no
> new features" reign, but personally I don't feel it is the most robust
> way to tackle the problem
FWIW, I agree. That's not to say that Lennart's not done a good job
and has put quite a lot of time or thought on it. He has. But I think
the fix is not very mature yet.
> and it also would require updating manual
> pages and documentation and stuff.
Documentation still requires updating wrt the TCP stuff. I haven't
done it because I'm waiting for the dust to settle regarding this
additional matter.
> So my personal feeling is that for 22.1, we should bring emacsclient
> under Windows merely up to what we already have under POSIX systems,
> and leave the design and testing of further improvements to 23.1
Agreed, again.
/L/e/k/t/u
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-11-19 14:13 ` Pretest Juanma Barranquero
2006-11-19 14:24 ` Pretest David Kastrup
@ 2006-11-20 12:59 ` Richard Stallman
1 sibling, 0 replies; 172+ messages in thread
From: Richard Stallman @ 2006-11-20 12:59 UTC (permalink / raw)
Cc: nickrob, emacs-devel
Lennart is *proposing* changes that would allow emacsclient to
automatically start Emacs if it is not running already.
Now is the wrong time. Please leave this for after the release!
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-11-19 21:50 ` Pretest Reiner Steib
@ 2006-11-20 12:59 ` Richard Stallman
0 siblings, 0 replies; 172+ messages in thread
From: Richard Stallman @ 2006-11-20 12:59 UTC (permalink / raw)
Cc: cyd, emacs-devel
Yes, that's the purpose of Mail-Followup-To. But only some MUAs
(Gnus, MH-E, mutt, ...) support it.
Alas, that probably means Mail-Followup-To isn't sufficient for this
purpose.
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-11-20 10:58 ` Pretest Juanma Barranquero
@ 2006-11-20 15:30 ` Stefan Monnier
2006-11-20 16:48 ` Pretest Juanma Barranquero
0 siblings, 1 reply; 172+ messages in thread
From: Stefan Monnier @ 2006-11-20 15:30 UTC (permalink / raw)
Cc: emacs-devel
>> and it also would require updating manual
>> pages and documentation and stuff.
> Documentation still requires updating wrt the TCP stuff. I haven't
> done it because I'm waiting for the dust to settle regarding this
> additional matter.
Don't wait: the two are unrelated.
Stefan
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-11-20 15:30 ` Pretest Stefan Monnier
@ 2006-11-20 16:48 ` Juanma Barranquero
0 siblings, 0 replies; 172+ messages in thread
From: Juanma Barranquero @ 2006-11-20 16:48 UTC (permalink / raw)
Cc: emacs-devel
On 11/20/06, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> Don't wait: the two are unrelated.
Lennart's changes would require adding new command-line options to
emacsclient, and I already have to document one (--server-file), so
not *totally* unrelated.
But I will try to find a bit of time to update the docs.
/L/e/k/t/u
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-11-20 9:01 ` Pretest Juanma Barranquero
2006-11-20 9:37 ` Pretest Jason Rumney
2006-11-20 10:01 ` Pretest David Kastrup
@ 2006-11-20 23:58 ` Richard Stallman
2006-11-21 0:05 ` Pretest Juanma Barranquero
2 siblings, 1 reply; 172+ messages in thread
From: Richard Stallman @ 2006-11-20 23:58 UTC (permalink / raw)
Cc: emacs-devel
As I demonstrated in a previous thread, I repeatedly asked on the
list.
But I never said to install it.
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-11-20 23:58 ` Pretest Richard Stallman
@ 2006-11-21 0:05 ` Juanma Barranquero
2006-11-22 13:15 ` Pretest Richard Stallman
0 siblings, 1 reply; 172+ messages in thread
From: Juanma Barranquero @ 2006-11-21 0:05 UTC (permalink / raw)
On 11/21/06, Richard Stallman <rms@gnu.org> wrote:
> But I never said to install it.
As for most other things installed.
/L/e/k/t/u
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2006-11-21 0:05 ` Pretest Juanma Barranquero
@ 2006-11-22 13:15 ` Richard Stallman
0 siblings, 0 replies; 172+ messages in thread
From: Richard Stallman @ 2006-11-22 13:15 UTC (permalink / raw)
Cc: emacs-devel
> But I never said to install it.
As for most other things installed.
That is often the case for small bug fixes
because there is no doubt that fixing the bugs is desirable.
^ permalink raw reply [flat|nested] 172+ messages in thread
* Pretest
@ 2007-03-18 4:28 Chong Yidong
2007-03-18 4:31 ` Pretest Juanma Barranquero
2007-03-20 1:34 ` Pretest Chong Yidong
0 siblings, 2 replies; 172+ messages in thread
From: Chong Yidong @ 2007-03-18 4:28 UTC (permalink / raw)
To: emacs-devel
This week's pretest didn't take place due to the savannah crash;
unless there are any serious objections, I'll roll a new pretest
tarball this coming Monday, the 19th.
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2007-03-18 4:28 Pretest Chong Yidong
@ 2007-03-18 4:31 ` Juanma Barranquero
2007-03-20 1:34 ` Pretest Chong Yidong
1 sibling, 0 replies; 172+ messages in thread
From: Juanma Barranquero @ 2007-03-18 4:31 UTC (permalink / raw)
To: Chong Yidong; +Cc: emacs-devel
On 18 Mar 2007 00:28:17 -0400, Chong Yidong <cyd@mit.edu> wrote:
> This week's pretest didn't take place due to the savannah crash;
> unless there are any serious objections, I'll roll a new pretest
> tarball this coming Monday, the 19th.
No objections, but the server.el issue is still unresolved / undecided.
Juanma
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2007-03-18 4:28 Pretest Chong Yidong
2007-03-18 4:31 ` Pretest Juanma Barranquero
@ 2007-03-20 1:34 ` Chong Yidong
2007-03-20 2:05 ` Pretest Juanma Barranquero
` (2 more replies)
1 sibling, 3 replies; 172+ messages in thread
From: Chong Yidong @ 2007-03-20 1:34 UTC (permalink / raw)
To: emacs-devel
I have rolled the 22.0.96 pretest tarball. It is available at the
usual location:
http://alpha.gnu.org/gnu/emacs/pretest/emacs-22.0.96.tar.gz
http://alpha.gnu.org/gnu/emacs/pretest/emacs-22.0.95-22.0.96.xdelta
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2007-03-20 1:34 ` Pretest Chong Yidong
@ 2007-03-20 2:05 ` Juanma Barranquero
2007-03-20 4:40 ` Pretest dhruva
2007-03-21 22:47 ` Pretest Lennart Borgman (gmail)
2 siblings, 0 replies; 172+ messages in thread
From: Juanma Barranquero @ 2007-03-20 2:05 UTC (permalink / raw)
To: Chong Yidong; +Cc: emacs-devel
On 3/20/07, Chong Yidong <cyd@stupidchicken.com> wrote:
> I have rolled the 22.0.96 pretest tarball.
Builds and works fine with gcc (GCC) 3.4.5 (mingw special) on Windows
XP Home Edition:
GNU Emacs 22.0.96.1 (i386-mingw-nt5.1.2600) of 2007-03-20 on LEKTU
Juanma
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2007-03-20 1:34 ` Pretest Chong Yidong
2007-03-20 2:05 ` Pretest Juanma Barranquero
@ 2007-03-20 4:40 ` dhruva
2007-03-20 12:07 ` Pretest AriT93
2007-03-21 22:47 ` Pretest Lennart Borgman (gmail)
2 siblings, 1 reply; 172+ messages in thread
From: dhruva @ 2007-03-20 4:40 UTC (permalink / raw)
To: Chong Yidong; +Cc: emacs-devel
Hi,
Builds and works (typical usage) fine on Windows Server 2003
(Enterprise edition) using Microsoft Visual Studio .NET 2003.
On 3/20/07, Chong Yidong <cyd@stupidchicken.com> wrote:
> I have rolled the 22.0.96 pretest tarball. It is available at the
> usual location:
>
> http://alpha.gnu.org/gnu/emacs/pretest/emacs-22.0.96.tar.gz
> http://alpha.gnu.org/gnu/emacs/pretest/emacs-22.0.95-22.0.96.xdelta
>
>
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel
>
--
Dhruva Krishnamurthy
Contents reflect my personal views only!
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2007-03-20 4:40 ` Pretest dhruva
@ 2007-03-20 12:07 ` AriT93
2007-03-20 12:36 ` Pretest dhruva
0 siblings, 1 reply; 172+ messages in thread
From: AriT93 @ 2007-03-20 12:07 UTC (permalink / raw)
To: dhruva; +Cc: Chong Yidong, emacs-devel
dhruva writes:
> Hi,
> Builds and works (typical usage) fine on Windows Server 2003
> (Enterprise edition) using Microsoft Visual Studio .NET 2003.
>
> On 3/20/07, Chong Yidong <cyd@stupidchicken.com> wrote:
> > I have rolled the 22.0.96 pretest tarball. It is available at the
> > usual location:
> >
> > http://alpha.gnu.org/gnu/emacs/pretest/emacs-22.0.96.tar.gz
> > http://alpha.gnu.org/gnu/emacs/pretest/emacs-22.0.95-22.0.96.xdelta
> >
> >
> --
> Dhruva Krishnamurthy
> Contents reflect my personal views only!
>
Just out of curiosity what steps did you take to get VS.NET 2003 to compile it.
I have been unable in the past to get that to work. I have always use GnuWin32
but would like to be able to use VS.NET as that environment is a bit easier to
maintain on my current workstation. Is it on the Wiki page?
--
enjoy every sandwich
-- W. Zevon
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2007-03-20 12:07 ` Pretest AriT93
@ 2007-03-20 12:36 ` dhruva
2007-03-20 13:14 ` Pretest AriT93
0 siblings, 1 reply; 172+ messages in thread
From: dhruva @ 2007-03-20 12:36 UTC (permalink / raw)
To: AriT93; +Cc: Chong Yidong, emacs-devel
Hi,
On 3/20/07, AriT93 <arit93@yahoo.com> wrote:
> dhruva writes:
> > Hi,
> > Builds and works (typical usage) fine on Windows Server 2003
> > (Enterprise edition) using Microsoft Visual Studio .NET 2003.
>
> Just out of curiosity what steps did you take to get VS.NET 2003 to compile it.
> I have been unable in the past to get that to work. I have always use GnuWin32
> but would like to be able to use VS.NET as that environment is a bit easier to
> maintain on my current workstation. Is it on the Wiki page?
- I have some of the basic GNU utils needed for build on WIN32 in my
PATH (like cp, rm, ls and a few others from GNUWIN32 project).
- I open the command shell "cmd.exe" and run a batch file "E:\Program
Files\Microsoft Visual Studio .NET 2003\Vc7\bin\VCVARS32.BAT" (the
path will vary based on the drive/folder you have installed VS.NET).
- Go to the emacs/nt folder and "configure --prefix=somedir --with-msvc"
- "nmake" and "namek install"
It is the batch file that you might have missed executing to get all
the compiler/linker paths set (VCVARS32.BAT). Let me know if you need
the env output resulting from VCVARS32.bat if you have any problems.
-dky
--
Dhruva Krishnamurthy
Contents reflect my personal views only!
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2007-03-09 17:46 Killing buffers with mouse Eli Zaretskii
@ 2007-03-20 13:04 ` Angelo Graziosi
0 siblings, 0 replies; 172+ messages in thread
From: Angelo Graziosi @ 2007-03-20 13:04 UTC (permalink / raw)
To: emacs-devel
Chong Yidong wrote:
> I have rolled the 22.0.96 pretest tarball. It is available at the
> usual location:
> http://alpha.gnu.org/gnu/emacs/pretest/emacs-22.0.96.tar.gz
> http://alpha.gnu.org/gnu/emacs/pretest/emacs-22.0.95-22.0.96.xdelta
(Pure) Cygwin binaries at:
http://www.webalice.it/angelo.graziosi/Emacs.html
Cheers,
Angelo.
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2007-03-20 12:36 ` Pretest dhruva
@ 2007-03-20 13:14 ` AriT93
0 siblings, 0 replies; 172+ messages in thread
From: AriT93 @ 2007-03-20 13:14 UTC (permalink / raw)
To: dhruva; +Cc: Chong Yidong, AriT93, emacs-devel
dhruva writes:
> Hi,
>
> On 3/20/07, AriT93 <arit93@yahoo.com> wrote:
> > dhruva writes:
> > > Hi,
> > > Builds and works (typical usage) fine on Windows Server 2003
> > > (Enterprise edition) using Microsoft Visual Studio .NET 2003.
> >
> > Just out of curiosity what steps did you take to get VS.NET 2003 to compile it.
> > I have been unable in the past to get that to work. I have always use GnuWin32
> > but would like to be able to use VS.NET as that environment is a bit easier to
> > maintain on my current workstation. Is it on the Wiki page?
>
> - I have some of the basic GNU utils needed for build on WIN32 in my
> PATH (like cp, rm, ls and a few others from GNUWIN32 project).
> - I open the command shell "cmd.exe" and run a batch file "E:\Program
> Files\Microsoft Visual Studio .NET 2003\Vc7\bin\VCVARS32.BAT" (the
> path will vary based on the drive/folder you have installed VS.NET).
> - Go to the emacs/nt folder and "configure --prefix=somedir --with-msvc"
> - "nmake" and "namek install"
>
> It is the batch file that you might have missed executing to get all
> the compiler/linker paths set (VCVARS32.BAT). Let me know if you need
> the env output resulting from VCVARS32.bat if you have any problems.
>
> -dky
>
> --
> Dhruva Krishnamurthy
> Contents reflect my personal views only!
>
Excellent! Thank you. Compiling now.
--
enjoy every sandwich
-- W. Zevon
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2007-03-20 1:34 ` Pretest Chong Yidong
2007-03-20 2:05 ` Pretest Juanma Barranquero
2007-03-20 4:40 ` Pretest dhruva
@ 2007-03-21 22:47 ` Lennart Borgman (gmail)
2 siblings, 0 replies; 172+ messages in thread
From: Lennart Borgman (gmail) @ 2007-03-21 22:47 UTC (permalink / raw)
To: Chong Yidong; +Cc: emacs-devel
Chong Yidong wrote:
> I have rolled the 22.0.96 pretest tarball. It is available at the
> usual location:
>
> http://alpha.gnu.org/gnu/emacs/pretest/emacs-22.0.96.tar.gz
> http://alpha.gnu.org/gnu/emacs/pretest/emacs-22.0.95-22.0.96.xdelta
I have some hours ago uploaded precompiled (unpatched) binaries to
http://ourcomments.org/cgi-bin/emacsw32-dl-latest.pl
^ permalink raw reply [flat|nested] 172+ messages in thread
* Pretest
2007-03-31 19:41 ` David Kastrup
@ 2007-03-31 20:02 ` Chong Yidong
0 siblings, 0 replies; 172+ messages in thread
From: Chong Yidong @ 2007-03-31 20:02 UTC (permalink / raw)
To: David Kastrup
Cc: David Reitter, Michael Albinus, Stefan Monnier, rms, emacs-devel
> I think this change warrants another pretest, preferably when the
> HPUX problems have been sorted out (or are they already?). If this
> can be achieved this weekend...
This weekend is probably too soon; let's make that Tuesday, April 3.
If there are no objections, I'll roll a new pretest tarball on that
date.
> ... and nothing else intervenes, next weekend could be our final
> target.
I would like that, but this is dependent on Kevin Rodger's papers
arriving (I guess RMS will inform us about that).
^ permalink raw reply [flat|nested] 172+ messages in thread
* Pretest
@ 2011-09-19 18:52 Chong Yidong
2011-09-19 21:13 ` Pretest Drew Adams
2011-09-19 22:29 ` Pretest Lars Magne Ingebrigtsen
0 siblings, 2 replies; 172+ messages in thread
From: Chong Yidong @ 2011-09-19 18:52 UTC (permalink / raw)
To: emacs-devel
Unless something comes up, I would like to make the first pretest this
Sunday, the 25th. Please plan your commits accordingly; thanks.
^ permalink raw reply [flat|nested] 172+ messages in thread
* RE: Pretest
2011-09-19 18:52 Pretest Chong Yidong
@ 2011-09-19 21:13 ` Drew Adams
2011-09-20 15:27 ` Pretest Chong Yidong
2011-09-19 22:29 ` Pretest Lars Magne Ingebrigtsen
1 sibling, 1 reply; 172+ messages in thread
From: Drew Adams @ 2011-09-19 21:13 UTC (permalink / raw)
To: 'Chong Yidong', emacs-devel
> Unless something comes up, I would like to make the first pretest this
> Sunday, the 25th. Please plan your commits accordingly; thanks.
Are you kidding? Or did you perhaps mean Sunday, Nov 25, 2012 (that sounds more
like it)?
After Martin relentlessly and carefully worked out the bugs from his humongous,
many-faceted, and detailed buffer-display changes, you suddenly changed it all
again (recently). And during a feature freeze, no less. Even Martin (our
resident window/buffer-display expert) has admitted that he does not yet
understand the new code.
Does that count as "something coming up"?
How much design, development, and testing time did you put into the new design,
compared to the hundreds of hours (perhaps 100s of days?) that Martin spent on
his approach? I'm not defending or attacking either design (I was OK with the
Emacs 18-23 one). I'm just asking about the relative effort and care expressed,
as one possible measure of how fully baked this might be.
There has hardly been time to collect reports of the fallout, let alone attempt
to repair the damage from this change. I've had the experience of only one
Windows build with the new approach, and there have been code changes since that
build. I immediately filed one bug - but got no reply to it of any substance
(http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9532#11). Think, for contrast,
how long you let people digest the lex-bind changes...
And AFAICT there is still no user-understandable doc explaining simply and
clearly how to use the new system and how to map pre-Emacs-24 behavior and
preferences to it. Not to mention a clear presentation of the changes in NEWS.
(Is there even an UNclear one? All I see is "FIXME: buffer-display-alist
changes").
I thought the decision about this (user-unrequested) feature was that we were
going to _take the time to get it right_. Two nano-seconds after a sudden
design change you want to start pretest? Bad.
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2011-09-19 18:52 Pretest Chong Yidong
2011-09-19 21:13 ` Pretest Drew Adams
@ 2011-09-19 22:29 ` Lars Magne Ingebrigtsen
2011-09-20 15:27 ` Pretest Chong Yidong
1 sibling, 1 reply; 172+ messages in thread
From: Lars Magne Ingebrigtsen @ 2011-09-19 22:29 UTC (permalink / raw)
To: emacs-devel
Chong Yidong <cyd@stupidchicken.com> writes:
> Unless something comes up, I would like to make the first pretest this
> Sunday, the 25th.
That's great news.
> Please plan your commits accordingly; thanks.
What changes in the bug-fixing department, though? We've been in a
feature freeze for a couple of months, like...
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog http://lars.ingebrigtsen.no/
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2011-09-19 22:29 ` Pretest Lars Magne Ingebrigtsen
@ 2011-09-20 15:27 ` Chong Yidong
0 siblings, 0 replies; 172+ messages in thread
From: Chong Yidong @ 2011-09-20 15:27 UTC (permalink / raw)
To: emacs-devel
Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>> Please plan your commits accordingly; thanks.
>
> What changes in the bug-fixing department, though?
Nothing, except that if a bug fix needs significant code changes, don't
wait till Sunday to check it in.
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2011-09-19 21:13 ` Pretest Drew Adams
@ 2011-09-20 15:27 ` Chong Yidong
2011-09-20 21:13 ` Pretest Andy Moreton
2011-09-21 1:27 ` Pretest Stefan Monnier
0 siblings, 2 replies; 172+ messages in thread
From: Chong Yidong @ 2011-09-20 15:27 UTC (permalink / raw)
To: Drew Adams; +Cc: emacs-devel
"Drew Adams" <drew.adams@oracle.com> writes:
> After Martin relentlessly and carefully worked out the bugs from his
> humongous, many-faceted, and detailed buffer-display changes, you
> suddenly changed it all again (recently). And during a feature
> freeze, no less. Even Martin (our resident window/buffer-display
> expert) has admitted that he does not yet understand the new code.
>
> Does that count as "something coming up"?
No.
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2011-09-20 15:27 ` Pretest Chong Yidong
@ 2011-09-20 21:13 ` Andy Moreton
2011-09-20 21:33 ` Pretest Chong Yidong
2011-09-21 1:27 ` Pretest Stefan Monnier
1 sibling, 1 reply; 172+ messages in thread
From: Andy Moreton @ 2011-09-20 21:13 UTC (permalink / raw)
To: emacs-devel
On Tue 20 Sep 2011, Chong Yidong wrote:
> "Drew Adams" <drew.adams@oracle.com> writes:
>
>> After Martin relentlessly and carefully worked out the bugs from his
>> humongous, many-faceted, and detailed buffer-display changes, you
>> suddenly changed it all again (recently). And during a feature
>> freeze, no less. Even Martin (our resident window/buffer-display
>> expert) has admitted that he does not yet understand the new code.
>>
>> Does that count as "something coming up"?
>
> No.
I think you dismiss Drew's concerns too lightly.
Where is the user level documentation comprehensible by mere mortals to
explain the new display code and its customisation ?
It seems to me that most ordinary users of emacs have little chance of
understanding what the new features are, never mind how to configure
emacs to their liking.
Please assuage my doubts by pointing out the relevant sections in the
manual.
AndyM
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2011-09-20 21:13 ` Pretest Andy Moreton
@ 2011-09-20 21:33 ` Chong Yidong
0 siblings, 0 replies; 172+ messages in thread
From: Chong Yidong @ 2011-09-20 21:33 UTC (permalink / raw)
To: Andy Moreton; +Cc: emacs-devel
Andy Moreton <andrewjmoreton@gmail.com> writes:
> Where is the user level documentation comprehensible by mere mortals
> to explain the new display code and its customisation ?
I've been working on it, and it should be ready by this weekend.
But in any case, complete manuals has never been a condition for
beginning an Emacs pretest; in previous release cycles, manual updates
were written during the first part of the pretest period.
^ permalink raw reply [flat|nested] 172+ messages in thread
* Re: Pretest
2011-09-20 15:27 ` Pretest Chong Yidong
2011-09-20 21:13 ` Pretest Andy Moreton
@ 2011-09-21 1:27 ` Stefan Monnier
2011-09-21 2:11 ` Pretest Drew Adams
1 sibling, 1 reply; 172+ messages in thread
From: Stefan Monnier @ 2011-09-21 1:27 UTC (permalink / raw)
To: Chong Yidong; +Cc: Drew Adams, emacs-devel
>> After Martin relentlessly and carefully worked out the bugs from his
>> humongous, many-faceted, and detailed buffer-display changes, you
>> suddenly changed it all again (recently). And during a feature
>> freeze, no less. Even Martin (our resident window/buffer-display
>> expert) has admitted that he does not yet understand the new code.
>> Does that count as "something coming up"?
> No.
Just to put some argument behind it: the new code that replaces Martin's
is not humongous, not many-faceted, ... instead it's a fairly small
change, localized change, with a reasonably clear "backward
compatibility argument".
That's why we haven't seen too many bug reports since this new scheme
has been installed.
Sadly, it goes much less far than Martin's change, so some of the more
interesting developments end up postponed to 24.2.
Stefan
^ permalink raw reply [flat|nested] 172+ messages in thread
* RE: Pretest
2011-09-21 1:27 ` Pretest Stefan Monnier
@ 2011-09-21 2:11 ` Drew Adams
0 siblings, 0 replies; 172+ messages in thread
From: Drew Adams @ 2011-09-21 2:11 UTC (permalink / raw)
To: 'Stefan Monnier', 'Chong Yidong'; +Cc: emacs-devel
> >> After Martin relentlessly and carefully worked out the
> >> bugs from his humongous, many-faceted, and detailed
> >> buffer-display changes, you suddenly changed it all again
> >> (recently). And during a feature freeze, no less. Even
> >> Martin (our resident window/buffer-display expert) has
> >> admitted that he does not yet understand the new code.
> >> Does that count as "something coming up"?
> >
> > No.
>
> Just to put some argument behind it: the new code that
> replaces Martin's is not humongous, not many-faceted, ...
> instead it's a fairly small change, localized change, with
> a reasonably clear "backward compatibility argument".
However simple, it still needs time for testing - pre-pretesting.
> That's why we haven't seen too many bug reports since this
> new scheme has been installed.
Is it a joke? I've had the new changes for a little over a week now, in Emacs
Windows builds. As soon as the changes were in, things were broken for me and I
filed a bug.
It's not surprising that few bugs have been reported yet - the change has not
been in the code for long. Reminds me of the elementary school teacher who
said, "Take-out-your-books--take-out-your-books--take-out-your-books. That's 3
times and your books aren't out yet!"
> Sadly, it goes much less far than Martin's change, so some of the more
> interesting developments end up postponed to 24.2.
I have no problem with that. My main concerns with this, or Martin's, or any
other such changes are (a) backward compatibility, (b) conceptual simplicity,
(c) usage simplicity, and (d) covering the use cases I use (hey, I'm one user)
as well as before (that is, once I've learned how to go beyond backward
compatibility and use the new system).
Martin's stuff never reached the point where people understood it enough to
explain it in simple terms. But it at least had the advantage (for me) that it
worked (for my use cases). I know that he spent a _lot_ of time fixing bugs to
cover various use cases: mine and those of others.
I have nothing against a new approach, if it covers the various use cases and it
is reasonably simple to use. But I think more than a couple of weeks should
pass before you declare it ready for pretest.
Presumably the reason (or at least one of the main reasons) for all these
changes is to simply the interface for users. And perhaps to cover more use
cases (dunno). I'm unaware of any users having actually asked for this
(solution looking for a problem?), but that's OK if it is really an improvement.
On the other hand, if it doesn't match the old system in simplicity and use-case
coverage, then I don't see the point. People need time to judge.
^ permalink raw reply [flat|nested] 172+ messages in thread
end of thread, other threads:[~2011-09-21 2:11 UTC | newest]
Thread overview: 172+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-09-19 18:52 Pretest Chong Yidong
2011-09-19 21:13 ` Pretest Drew Adams
2011-09-20 15:27 ` Pretest Chong Yidong
2011-09-20 21:13 ` Pretest Andy Moreton
2011-09-20 21:33 ` Pretest Chong Yidong
2011-09-21 1:27 ` Pretest Stefan Monnier
2011-09-21 2:11 ` Pretest Drew Adams
2011-09-19 22:29 ` Pretest Lars Magne Ingebrigtsen
2011-09-20 15:27 ` Pretest Chong Yidong
-- strict thread matches above, loose matches on Subject: below --
2007-03-26 3:52 [david.reitter@gmail.com: file-remote-p malfunctions at site-start (file-name-handler-alist init)] Richard Stallman
2007-03-26 4:40 ` Chong Yidong
2007-03-26 13:14 ` Stefan Monnier
2007-03-26 13:37 ` Michael Albinus
2007-03-26 14:16 ` Chong Yidong
2007-03-26 14:44 ` Michael Albinus
2007-03-27 20:59 ` Chong Yidong
2007-03-31 18:47 ` Michael Albinus
2007-03-31 19:41 ` David Kastrup
2007-03-31 20:02 ` Pretest Chong Yidong
2007-03-18 4:28 Pretest Chong Yidong
2007-03-18 4:31 ` Pretest Juanma Barranquero
2007-03-20 1:34 ` Pretest Chong Yidong
2007-03-20 2:05 ` Pretest Juanma Barranquero
2007-03-20 4:40 ` Pretest dhruva
2007-03-20 12:07 ` Pretest AriT93
2007-03-20 12:36 ` Pretest dhruva
2007-03-20 13:14 ` Pretest AriT93
2007-03-21 22:47 ` Pretest Lennart Borgman (gmail)
2007-03-09 17:46 Killing buffers with mouse Eli Zaretskii
2007-03-20 13:04 ` Pretest Angelo Graziosi
2006-11-18 22:14 Pretest Chong Yidong
2006-11-18 22:58 ` Pretest Lennart Borgman
2006-11-18 23:32 ` Pretest Chong Yidong
2006-11-19 0:53 ` Pretest Juanma Barranquero
2006-11-19 0:56 ` Pretest Nick Roberts
2006-11-19 1:01 ` Pretest Juanma Barranquero
2006-11-19 1:56 ` Pretest Nick Roberts
2006-11-19 2:04 ` Pretest Juanma Barranquero
2006-11-19 3:29 ` Pretest Nick Roberts
2006-11-19 8:45 ` Pretest David Kastrup
2006-11-19 10:03 ` Pretest Nick Roberts
2006-11-19 10:18 ` Pretest David Kastrup
2006-11-19 11:44 ` Pretest Nick Roberts
2006-11-19 14:13 ` Pretest Juanma Barranquero
2006-11-19 14:24 ` Pretest David Kastrup
2006-11-19 14:42 ` Pretest Juanma Barranquero
2006-11-19 14:45 ` Pretest Lennart Borgman
2006-11-19 15:58 ` Pretest David Kastrup
2006-11-19 19:13 ` Pretest Lennart Borgman
2006-11-19 19:27 ` Pretest David Kastrup
2006-11-20 1:15 ` Pretest Stefan Monnier
2006-11-19 17:54 ` Pretest Jason Rumney
2006-11-19 19:14 ` Pretest Lennart Borgman
2006-11-19 19:50 ` Pretest Jason Rumney
2006-11-19 20:48 ` Pretest David Kastrup
2006-11-19 21:33 ` Pretest Lennart Borgman
2006-11-19 21:33 ` Pretest Jason Rumney
2006-11-19 21:49 ` Pretest David Kastrup
2006-11-19 22:04 ` Pretest Jason Rumney
2006-11-19 22:06 ` Pretest Lennart Borgman
2006-11-19 22:44 ` Pretest David Kastrup
2006-11-19 23:02 ` Pretest Lennart Borgman
2006-11-19 23:31 ` Pretest David Kastrup
2006-11-20 0:59 ` Pretest Lennart Borgman
2006-11-20 1:20 ` Pretest David Kastrup
[not found] ` <45616414.2080802@student.lu.se>
2006-11-20 9:55 ` Pretest David Kastrup
2006-11-20 1:20 ` Pretest Stefan Monnier
2006-11-19 21:34 ` Pretest Lennart Borgman
2006-11-19 21:38 ` Pretest Lennart Borgman
2006-11-20 12:59 ` Pretest Richard Stallman
2006-11-19 14:19 ` Pretest Juanma Barranquero
2006-11-20 1:37 ` Pretest Richard Stallman
2006-11-20 3:00 ` Pretest Stefan Monnier
2006-11-20 9:01 ` Pretest Juanma Barranquero
2006-11-20 9:37 ` Pretest Jason Rumney
2006-11-20 10:06 ` Pretest Juanma Barranquero
2006-11-20 10:50 ` Pretest David Kastrup
2006-11-20 10:58 ` Pretest Juanma Barranquero
2006-11-20 15:30 ` Pretest Stefan Monnier
2006-11-20 16:48 ` Pretest Juanma Barranquero
2006-11-20 10:01 ` Pretest David Kastrup
2006-11-20 23:58 ` Pretest Richard Stallman
2006-11-21 0:05 ` Pretest Juanma Barranquero
2006-11-22 13:15 ` Pretest Richard Stallman
2006-11-19 12:48 ` Pretest Richard Stallman
2006-11-19 20:08 ` Pretest Eli Zaretskii
2006-11-19 21:50 ` Pretest Reiner Steib
2006-11-20 12:59 ` Pretest Richard Stallman
2006-11-19 19:59 ` Pretest Eli Zaretskii
2006-11-07 20:13 Pretest Nick Roberts
2006-11-07 22:48 ` Pretest Miles Bader
2006-11-08 1:17 ` Pretest Nick Roberts
2006-11-08 1:41 ` Pretest Miles Bader
2006-10-28 20:33 Pretest Mikko Huhtala
2006-10-27 17:59 Pretest Chong Yidong
2006-10-27 18:52 ` Pretest Paul Pogonyshev
2006-10-27 19:12 ` Pretest David Hansen
2006-10-28 11:31 ` Pretest Eli Zaretskii
2006-11-15 21:35 ` Pretest Reiner Steib
2006-11-15 22:51 ` Pretest Nick Roberts
2006-10-27 19:38 ` Pretest Kim F. Storm
2006-10-28 11:17 ` Pretest Eli Zaretskii
2006-10-29 18:45 ` Pretest Richard Stallman
2006-10-29 20:20 ` Pretest Eli Zaretskii
2006-10-27 20:01 ` Pretest joakim
2006-10-27 21:11 ` Pretest Giorgos Keramidas
2006-10-28 2:30 ` Pretest Andrew M. Scott
2006-10-28 8:11 ` Pretest Yoni Rabkin Katzenell
2006-10-28 8:46 ` Pretest Andreas Roehler
2006-10-28 11:01 ` Pretest Jason Rumney
2006-10-28 13:14 ` Pretest Eli Zaretskii
2006-10-28 21:47 ` Pretest Jason Rumney
2006-10-29 4:30 ` Pretest Eli Zaretskii
2006-10-29 11:17 ` Pretest Jason Rumney
2006-10-29 11:47 ` Pretest Eli Zaretskii
2006-10-30 13:33 ` Pretest Richard Stallman
2006-10-30 21:12 ` Pretest Eli Zaretskii
2006-11-01 2:12 ` Pretest Richard Stallman
2006-11-04 12:15 ` Pretest Eli Zaretskii
2006-11-04 22:23 ` Pretest Jason Rumney
2006-11-05 6:15 ` Pretest Eli Zaretskii
2006-11-05 12:39 ` Pretest Jason Rumney
2006-11-05 12:41 ` Pretest Jason Rumney
2006-10-28 11:13 ` Pretest Eli Zaretskii
2006-10-28 13:30 ` Pretest Benjamin Riefenstahl
2006-10-28 15:25 ` Pretest Chong Yidong
2006-10-28 13:38 ` Pretest Eli Zaretskii
2006-10-28 15:53 ` Pretest Chong Yidong
2006-10-28 19:05 ` Pretest Eli Zaretskii
2006-10-29 21:36 ` Pretest Chong Yidong
2006-10-30 4:25 ` Pretest Eli Zaretskii
2006-10-30 14:21 ` Pretest Chong Yidong
2006-10-28 14:28 ` Pretest Eli Zaretskii
2006-10-28 15:01 ` Pretest Chong Yidong
2006-10-28 19:28 ` Pretest Eli Zaretskii
2006-10-28 20:47 ` Pretest Chong Yidong
2006-10-29 7:43 ` Pretest Eli Zaretskii
2006-10-29 22:11 ` Pretest Chong Yidong
2006-10-30 21:50 ` Pretest Eli Zaretskii
2006-10-30 22:04 ` Pretest Chong Yidong
2006-10-31 4:09 ` Pretest Eli Zaretskii
2006-10-30 13:33 ` Pretest Richard Stallman
2006-10-30 21:02 ` Pretest Eli Zaretskii
2006-11-01 2:12 ` Pretest Richard Stallman
2006-11-01 4:14 ` Pretest Eli Zaretskii
2006-11-02 4:42 ` Pretest Richard Stallman
2006-11-02 19:54 ` Pretest Eli Zaretskii
2006-11-03 7:08 ` Pretest Richard Stallman
2006-11-04 13:50 ` Pretest Eli Zaretskii
2006-11-05 7:08 ` Pretest Richard Stallman
[not found] ` <cyd@stupidchicken.com>
2006-10-28 15:08 ` Pretest Alfred M. Szmidt
2006-10-28 20:52 ` Pretest Chong Yidong
2006-10-28 21:11 ` Pretest Alfred M. Szmidt
2006-10-28 22:09 ` Pretest Chong Yidong
2006-10-28 22:30 ` Pretest Alfred M. Szmidt
2006-10-29 23:40 ` Pretest Chong Yidong
2006-10-30 0:33 ` Pretest Alfred M. Szmidt
2006-10-30 14:12 ` Pretest Chong Yidong
2006-10-30 19:57 ` Pretest Alfred M. Szmidt
2006-10-30 20:18 ` Pretest Chong Yidong
2006-10-30 20:34 ` Pretest Alfred M. Szmidt
2006-10-30 22:18 ` Pretest Chong Yidong
2006-10-30 23:00 ` Pretest Alfred M. Szmidt
2006-11-01 2:12 ` Pretest Richard Stallman
2006-11-02 14:10 ` Pretest Alfred M. Szmidt
2006-10-28 18:13 ` Pretest Richard Stallman
2006-10-28 19:02 ` Pretest Eli Zaretskii
2006-10-29 18:49 ` Pretest Richard Stallman
2006-10-29 20:22 ` Pretest Eli Zaretskii
2006-10-30 19:16 ` Pretest Richard Stallman
2006-11-03 15:39 ` Pretest Drew Adams
2006-11-03 19:22 ` Pretest Eli Zaretskii
2006-11-03 19:51 ` Pretest Lennart Borgman
2006-11-03 20:02 ` Pretest Eli Zaretskii
2006-11-03 20:48 ` Pretest Nick Roberts
2006-11-04 15:26 ` Pretest Richard Stallman
2006-10-30 20:04 ` Pretest Paul Jarc
2006-10-30 23:13 ` Pretest Chong Yidong
2006-10-31 9:44 ` Pretest Jim Thompson
2006-11-05 23:30 ` Pretest Bill Wohler
2006-11-06 0:01 ` Pretest Jason Rumney
2006-11-06 4:22 ` Pretest Eli Zaretskii
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).