Pretest

Pretest

[Chong Yidong]

Unless something comes up, I would like to make the first pretest this
Sunday, the 25th.  Please plan your commits accordingly; thanks.

RE: Pretest

[Drew Adams]

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

Re: Pretest

[Chong Yidong]

"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.

Re: Pretest

[Andy Moreton]

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

Re: Pretest

[Chong Yidong]

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.

Re: Pretest

[Stefan Monnier]

>> 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

RE: Pretest

[Drew Adams]

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

Re: Pretest

[Lars Magne Ingebrigtsen]

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/

Re: Pretest

[Chong Yidong]

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.

[david.reitter@gmail.com: file-remote-p malfunctions at site-start (file-name-handler-alist init)]

[Richard Stallman]

Would someone please DTRT and ack?

------- Start of forwarded message -------
X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY 
	autolearn=failed version=3.1.0
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta;
	h=domainkey-signature:received:received:mime-version:content-transfer-encoding:message-id:content-type:to:from:subject:date:x-mailer;
	b=s7BXyK+4GhOwW5H7jKdX9z5Vz4neRHIL2YqUkZgGtU6dWuhYC6BcFujLBLTrEPa09HRu0Di1NCR+jtLHuvR4f9wY8gC61A0libpAcUGY0k3ZK74H15WvMZn8c8NIzrWp3RcglmnIRhACDhqT0m5q3Y7doc4c2PboX/AjM3A+Cdw=
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
To: emacs-pretest-bug@gnu.org
From: David Reitter <david.reitter@gmail.com>
Date: Fri, 23 Mar 2007 21:53:59 +0000
Subject: file-remote-p malfunctions at site-start (file-name-handler-alist
	init)

If a site-start.el file is created with the following contents:

(print file-name-handler-alist)
(print (file-remote-p "/ssh:dreitter@ssh:/home/dreitter/test2"))

the output of the last expression is nil for me.
It should (correctly) be non-nil.


The reason for that is that `file-name-handler-alist' does not  
contain handlers for tramp file names when the site-start file is  
loaded - at a later point, the appropriate handlers are added.

The practical relevance is that when users (or site or distribution  
admins) load and turn on recentf-mode from a site-start file together  
with a `file-remote-p' predicate in `recentf-keep', then all recent- 
file entries containing a tramp path will be purged. That's very  
inconvenient.

The problem would go away if `file-name-handler-alist' was correctly  
initialized before site-start files are executed. Additionally,  
please consider defining the handler function for tramp files  
somewhere outside of tramp so that `file-remote-p' doesn't cause  
tramp to load just because it is checked for some file.





If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
     `bt full' and `xbacktrace'.
If you would like to further debug the crash, please read the file
/Applications/Emacs.app/Contents/Resources/etc/DEBUG for instructions.


In GNU Emacs 22.0.96.1 (powerpc-apple-darwin7.9.0, Carbon Version 1.6.0)
of 2007-03-22 on rodrigues.inf.ed.ac.uk
Windowing system distributor `Apple Inc.', version 10.4.9
configured using `configure  '--without-x' '--prefix=/usr/local''

Important settings:
   value of $LC_ALL: nil
   value of $LC_COLLATE: nil
   value of $LC_CTYPE: nil
   value of $LC_MESSAGES: nil
   value of $LC_MONETARY: nil
   value of $LC_NUMERIC: nil
   value of $LC_TIME: nil
   value of $LANG: nil
   locale-coding-system: iso-8859-1
   default-enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
   encoded-kbd-mode: t
   tooltip-mode: t
   tool-bar-mode: t
   mouse-wheel-mode: t
   menu-bar-mode: t
   file-name-shadow-mode: t
   global-font-lock-mode: t
   font-lock-mode: t
   blink-cursor-mode: t
   unify-8859-on-encoding-mode: t
   utf-translate-cjk-mode: t
   auto-compression-mode: t
   line-number-mode: t

Recent input:
<down-mouse-1> <mouse-1> <help-echo> <help-echo> <help-echo>
<menu-bar> <help-menu> <report-emacs-bug>

Recent messages:

(("\\.Z\\(~\\|\\.~[0-9]+~\\)?\\'\\|\\.bz2\\(~\\|\\.~[0-9]+~\\)?\\'\\|\ 
\.tbz\\'\\|\\.tgz\\'\\|\\.g?z\\(~\\|\\.~[0-9]+~\\)?\\'\\|\\.dz\\'" .  
jka-compr-handler) ("\\`/:" . file-name-non-special))

nil

For information about the GNU Project and its goals, type C-h C-p. [2  
times]
Loading emacsbug...
Loading regexp-opt...done
Loading emacsbug...done
Loading encoded-kb...done



_______________________________________________
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
------- End of forwarded message -------

Re: [david.reitter@gmail.com: file-remote-p malfunctions at site-start (file-name-handler-alist init)]

[Chong Yidong]

> If a site-start.el file is created with the following contents:
>
> (print file-name-handler-alist)
> (print (file-remote-p "/ssh:dreitter@ssh:/home/dreitter/test2"))
>
> the output of the last expression is nil for me.
> It should (correctly) be non-nil.
>
> The reason for that is that `file-name-handler-alist' does not
> contain handlers for tramp file names when the site-start file is
> loaded - at a later point, the appropriate handlers are added.

This could conceivably be achieved by moving
tramp-register-file-name-handlers from after-init-hook to
before-init-hook.  On the other hand, the risk of making a change to
the init sequence at this stage probably outweighs the marginal
benefit; I don't think the above is a very common scenario.

What do people think?

Re: [david.reitter@gmail.com: file-remote-p malfunctions at site-start (file-name-handler-alist init)]

[Stefan Monnier]

> This could conceivably be achieved by moving
> tramp-register-file-name-handlers from after-init-hook to
> before-init-hook.

Why is it done so late?  Why not do it at dump time?


        Stefan

Re: [david.reitter@gmail.com: file-remote-p malfunctions at site-start (file-name-handler-alist init)]

[Michael Albinus]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> This could conceivably be achieved by moving
>> tramp-register-file-name-handlers from after-init-hook to
>> before-init-hook.
>
> Why is it done so late?  Why not do it at dump time?

It was there initially. Then it was changed, because people didn't
want to get Tramp enabled mandatory for file name completion. Now the
registration is done only in case `partial-completion-mode' is
active, which must be checked. The comment in the code says

;; During autoload, it shall be checked whether
;; `partial-completion-mode' is active.  Therefore registering will be
;; delayed.

See also <http://lists.gnu.org/archive/html/emacs-devel/2006-05/msg00017.html>

>         Stefan

Best regards, Michael.

Re: [david.reitter@gmail.com: file-remote-p malfunctions at site-start (file-name-handler-alist init)]

[Chong Yidong]

Michael Albinus <michael.albinus@gmx.de> writes:

>>> This could conceivably be achieved by moving
>>> tramp-register-file-name-handlers from after-init-hook to
>>> before-init-hook.
>>
>> Why is it done so late?  Why not do it at dump time?
>
> It was there initially. Then it was changed, because people didn't
> want to get Tramp enabled mandatory for file name completion. Now the
> registration is done only in case `partial-completion-mode' is
> active, which must be checked.

In that case, I suggest documenting this in PROBLEMS: if you want to
use Tramp in your site-start file, run tramp-register-file-name-handlers
first (and remove it from after-init-hook).

Re: [david.reitter@gmail.com: file-remote-p malfunctions at site-start (file-name-handler-alist init)]

[Michael Albinus]

Chong Yidong <cyd@stupidchicken.com> writes:

>> It was there initially. Then it was changed, because people didn't
>> want to get Tramp enabled mandatory for file name completion. Now the
>> registration is done only in case `partial-completion-mode' is
>> active, which must be checked.
>
> In that case, I suggest documenting this in PROBLEMS: if you want to
> use Tramp in your site-start file, run tramp-register-file-name-handlers
> first (and remove it from after-init-hook).

I haven't a better idea. Maybe one should argue that it isn't a good
idea to access remote files in site-init files.

Note that removing tramp-register-file-name-handlers from
after-init-hook is not necessary, the registration is re-entrant.

OTOH, the OP gave as practical example recentf-mode problems with
remote files (handled in site-init). It would require changes in
recentf at least.

Best regards, Michael.

Re: [david.reitter@gmail.com: file-remote-p malfunctions at site-start (file-name-handler-alist init)]

[Chong Yidong]

Michael Albinus <michael.albinus@gmx.de> writes:

>> In that case, I suggest documenting this in PROBLEMS: if you want to
>> use Tramp in your site-start file, run tramp-register-file-name-handlers
>> first (and remove it from after-init-hook).
>
> I haven't a better idea. Maybe one should argue that it isn't a good
> idea to access remote files in site-init files.

OK, I documented it in PROBLEMS.

Re: [david.reitter@gmail.com: file-remote-p malfunctions at site-start (file-name-handler-alist init)]

[Michael Albinus]

Chong Yidong <cyd@stupidchicken.com> writes:

> Michael Albinus <michael.albinus@gmx.de> writes:
>
>> I haven't a better idea. Maybe one should argue that it isn't a good
>> idea to access remote files in site-init files.
>
> OK, I documented it in PROBLEMS.

Finally, I've divided `tramp-register-file-name-handlers' into two
parts, which are evaluated at different startup places. This should
solve the problem.

Best regards, Michael.

Re: [david.reitter@gmail.com: file-remote-p malfunctions at site-start (file-name-handler-alist init)]

[David Kastrup]

Michael Albinus <michael.albinus@gmx.de> writes:

> Chong Yidong <cyd@stupidchicken.com> writes:
>
>> Michael Albinus <michael.albinus@gmx.de> writes:
>>
>>> I haven't a better idea. Maybe one should argue that it isn't a good
>>> idea to access remote files in site-init files.
>>
>> OK, I documented it in PROBLEMS.
>
> Finally, I've divided `tramp-register-file-name-handlers' into two
> parts, which are evaluated at different startup places. This should
> solve the problem.

Tramp is a central part of the file access infrastructure.  So 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 and nothing else intervenes, next weekend could
be our final target.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Pretest

[Chong Yidong]

> 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).

Pretest

[Chong Yidong]

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.

Re: Pretest

[Juanma Barranquero]

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

Re: Pretest

[Chong Yidong]

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

Re: Pretest

[Juanma Barranquero]

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

Re: Pretest

[dhruva]

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!

Re: Pretest

[AriT93]

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

Re: Pretest

[dhruva]

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!

Re: Pretest

[AriT93]

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

Re: Pretest

[Lennart Borgman (gmail)]

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

Re: Killing buffers with mouse

[Eli Zaretskii]

> Date: Fri, 9 Mar 2007 17:46:51 +0100 (MET)
> From: Angelo Graziosi <Angelo.Graziosi@roma1.infn.it>
> cc: Chong Yidong <cyd@stupidchicken.com>,
>         =?ISO-8859-1?Q?Jan_Dj=E4rv?= <jan.h.d@swipnet.se>,
>         Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org
> 
> > 
> > Angelo, please tell what do you see in the buffer displayed by "C-h l"
> > after you move the wheel over that toolbar icon.  (That's a letter
> > ell, not the digit one in "C-h l".)
> > 
> 
> Regarding this point, after moving the wheel, C-h l (the lowercase of L),
> I have an help buffer:
> 
> ---------------------------------------------
> <help-echo> <help-echo> <down-mouse-1> <mouse-1> <help-echo>
> <down-mouse-3> <mouse-3> <double-down-mouse-3> <double-mouse-3>
> <help-echo> <help-echo> <tool-bar> <kill-buffer> <help-echo>
> <help-echo> <down-mouse-1> <drag-mouse-1> <help-echo>
> <help-echo> <down-mouse-2> <mouse-2> <down-mouse-5>
> <mouse-5> <help-echo> <help-echo> <help-echo> <tool-bar>
> <kill-buffer> <help-echo> <help-echo> C-h l <help-echo>
> <help-echo> <down-mouse-1> <mouse-1> <down-mouse-1>
> <mouse-movement> <mouse-movement> <help-echo> <mouse-movement>
> <mouse-movement> <mouse-movement> <mouse-movement>
> <mouse-movement> <help-echo> <mouse-movement> <mouse-movement>
> <drag-mouse-1> <help-echo> <help-echo> <help-echo>
> <down-mouse-1> <mouse-1> <help-echo> <down-mouse-2>
> <mouse-2> <help-echo> <down-mouse-1> <mouse-1> <help-echo>
> <down> <return> <return> C-y <help-echo> <help-echo>
> <help-echo> <help-echo> <help-echo> <help-echo> <tool-bar>
> <save-buffer> <help-echo> <help-echo> <down-mouse-3>
> <mouse-3> <help-echo> <help-echo> <tool-bar> <open-file>
> <help-echo> <up> <up> <up> <return> <help-echo> <tool-bar>
> <open-file> <up> <up> <up> <return> <help-echo> <help-echo>
> <help-echo> <tool-bar> <kill-buffer> C-h l
> ---------------------------------------------
> 
> but I am not sure that what you mean is what I have understood.

That's exactly what I meant, thank you.

As seen from the rest of this thread, the problem has been identified
already, and it is not specific to Cygwin.

Re: Pretest

[Angelo Graziosi]

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.

Pretest

[Chong Yidong]

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.

Re: Pretest

[Lennart Borgman]

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.

Re: Pretest

[Chong Yidong]

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.

Re: Pretest

[Juanma Barranquero]

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

Re: Pretest

[Nick Roberts]

 > > 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

Re: Pretest

[Juanma Barranquero]

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

Re: Pretest

[Nick Roberts]

 > > 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

Re: Pretest

[Juanma Barranquero]

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

Re: Pretest

[Nick Roberts]

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

Re: Pretest

[David Kastrup]

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

Re: Pretest

[Nick Roberts]

 > >  > 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

Re: Pretest

[David Kastrup]

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

Re: Pretest

[Nick Roberts]

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

Re: Pretest

[Juanma Barranquero]

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

Re: Pretest

[David Kastrup]

"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

Re: Pretest

[Juanma Barranquero]

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

Re: Pretest

[Lennart Borgman]

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.

Re: Pretest

[David Kastrup]

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

Re: Pretest

[Lennart Borgman]

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.)

Re: Pretest

[David Kastrup]

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

Re: Pretest

[Stefan Monnier]

> 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

Re: Pretest

[Jason Rumney]

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.

Re: Pretest

[Lennart Borgman]

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.

Re: Pretest

[Jason Rumney]

Jason Rumney wrote:
> In the most important use case, we don't want to wait.
I meant we DO want to wait here.

Re: Pretest

[David Kastrup]

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

Re: Pretest

[Lennart Borgman]

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 ;-)

Re: Pretest

[Jason Rumney]

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.

Re: Pretest

[David Kastrup]

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

Re: Pretest

[Jason Rumney]

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.

Re: Pretest

[Lennart Borgman]

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?

Re: Pretest

[David Kastrup]

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

Re: Pretest

[Lennart Borgman]

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.

Re: Pretest

[David Kastrup]

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

Re: Pretest

[Lennart Borgman]

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.

Re: Pretest

[David Kastrup]

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

Re: Pretest

[David Kastrup]

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

Re: Pretest

[Stefan Monnier]

> 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

Re: Pretest

[Lennart Borgman]

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 ;-)

Re: Pretest

[Lennart Borgman]

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 ;-)

Re: Pretest

[Richard Stallman]

    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!

Re: Pretest

[Juanma Barranquero]

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

Re: Pretest

[Richard Stallman]

    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?

Re: Pretest

[Stefan Monnier]

>     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

Re: Pretest

[Juanma Barranquero]

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

Re: Pretest

[Jason Rumney]

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.

Re: Pretest

[Juanma Barranquero]

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

Re: Pretest

[David Kastrup]

"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

Re: Pretest

[Juanma Barranquero]

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

Re: Pretest

[Stefan Monnier]

>> 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

Re: Pretest

[Juanma Barranquero]

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

Re: Pretest

[David Kastrup]

"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

Re: Pretest

[Richard Stallman]

    As I demonstrated in a previous thread, I repeatedly asked on the
    list.

But I never said to install it.

Re: Pretest

[Juanma Barranquero]

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

Re: Pretest

[Richard Stallman]

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

Re: Pretest

[Richard Stallman]

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?

Re: Pretest

[Eli Zaretskii]

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

Re: Pretest

[Reiner Steib]

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/

Re: Pretest

[Richard Stallman]

    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.

Re: Pretest

[Eli Zaretskii]

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

Re: Pretest

[Nick Roberts]

>         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

Re: Pretest

[Miles Bader]

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]

Re: Pretest

[Nick Roberts]

 > > 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

Re: Pretest

[Miles Bader]

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."

Re: Pretest

[Mikko Huhtala]

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

Pretest

[Chong Yidong]

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.

Re: Pretest

[Paul Pogonyshev]

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

Re: Pretest

[David Hansen]

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

Re: Pretest

[Eli Zaretskii]

> 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?

Re: Pretest

[Reiner Steib]

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/

Re: Pretest

[Nick Roberts]

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

Re: Pretest

[Kim F. Storm]

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

Re: Pretest

[Eli Zaretskii]

> 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?

Re: Pretest

[Richard Stallman]

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.

Re: Pretest

[Eli Zaretskii]

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

Re: Pretest

[joakim]

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

Re: Pretest

[Giorgos Keramidas]

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

Re: Pretest

[Andrew M. Scott]

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

Re: Pretest

[Yoni Rabkin Katzenell]

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"

Re: Pretest

[Andreas Roehler]

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
>
>   

Re: Pretest

[Jason Rumney]

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.

Re: Pretest

[Eli Zaretskii]

> 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

Re: Pretest

[Jason Rumney]

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?

Re: Pretest

[Eli Zaretskii]

> 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".

Re: Pretest

[Jason Rumney]

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.

Re: Pretest

[Eli Zaretskii]

> 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?

Re: Pretest

[Richard Stallman]

    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.

Re: Pretest

[Eli Zaretskii]

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

Re: Pretest

[Richard Stallman]

    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.

Re: Pretest

[Eli Zaretskii]

> 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?

Re: Pretest

[Jason Rumney]

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.

Re: Pretest

[Eli Zaretskii]

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

Re: Pretest

[Jason Rumney]

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.

Re: Pretest

[Jason Rumney]

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.

Re: Pretest

[Eli Zaretskii]

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

Re: Pretest

[Benjamin Riefenstahl]

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

Re: Pretest

[Chong Yidong]

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.

Re: Pretest

[Eli Zaretskii]

> 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.)

Re: Pretest

[Chong Yidong]

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.

Re: Pretest

[Eli Zaretskii]

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

Re: Pretest

[Chong Yidong]

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.

Re: Pretest

[Eli Zaretskii]

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

Re: Pretest

[Chong Yidong]

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.

Re: Pretest

[Eli Zaretskii]

> 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

Re: Pretest

[Chong Yidong]

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?

Re: Pretest

[Eli Zaretskii]

> 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

Re: Pretest

[Chong Yidong]

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.

Re: Pretest

[Eli Zaretskii]

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

Re: Pretest

[Chong Yidong]

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?

Re: Pretest

[Eli Zaretskii]

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

Re: Pretest

[Chong Yidong]

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' \
 `"]

Re: Pretest

[Eli Zaretskii]

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

Re: Pretest

[Richard Stallman]

    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.

Re: Pretest

[Eli Zaretskii]

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

Re: Pretest

[Richard Stallman]

    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 

Re: Pretest

[Eli Zaretskii]

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

Re: Pretest

[Richard Stallman]

    > 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?

Re: Pretest

[Eli Zaretskii]

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

Re: Pretest

[Richard Stallman]

    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.

Re: Pretest

[Eli Zaretskii]

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

Re: Pretest

[Richard Stallman]

    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.

Re: Pretest

[Alfred M. Szmidt]

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

Re: Pretest

[Chong Yidong]

"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

Re: Pretest

[Alfred M. Szmidt]

   > It doesn't build on OpenBSD:

   Is this x86-64 OpenBSD?

No, this is plain 8x86 OpenBSD.

Re: Pretest

[Chong Yidong]

"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?

Re: Pretest

[Alfred M. Szmidt]

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

Re: Pretest

[Chong Yidong]

"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

Re: Pretest

[Alfred M. Szmidt]

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

Re: Pretest

[Chong Yidong]

"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?

Re: Pretest

[Alfred M. Szmidt]

   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

Re: Pretest

[Chong Yidong]

"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?

Re: Pretest

[Alfred M. Szmidt]

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

Re: Pretest

[Chong Yidong]

"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

Re: Pretest

[Alfred M. Szmidt]

   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!

Re: Pretest

[Richard Stallman]

       > -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.)

Re: Pretest

[Alfred M. Szmidt]

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

Re: Pretest

[Richard Stallman]

    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.

Re: Pretest

[Eli Zaretskii]

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

Re: Pretest

[Richard Stallman]

    > 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?

Re: Pretest

[Eli Zaretskii]

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

Re: Pretest

[Richard Stallman]

    I think emacs-pretest-bug@gnu.org is the right address to put there.

Ok, that makes sense.

RE: Pretest

[Drew Adams]

Not sure how the pretest works. Will binary versions be posted somewhere, or
will people need to roll their own?

Re: Pretest

[Eli Zaretskii]

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

Re: Pretest

[Lennart Borgman]

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.

Re: Pretest

[Eli Zaretskii]

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

RE: Pretest

[Nick Roberts]

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

Re: Pretest

[Richard Stallman]

    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.

Re: Pretest

[Paul Jarc]

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

Re: Pretest

[Chong Yidong]

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.

Re: Pretest

[Jim Thompson]

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

Re: Pretest

[Bill Wohler]

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

Re: Pretest

[Jason Rumney]

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.

Re: Pretest

[Eli Zaretskii]

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