Re: Any issues that would hold up release of 4.6.1?

[Ethan A M. <sf...@us...>]

> On Monday, September 17, 2012 04:08:25 pm Ethan A Merritt wrote:
> > Is anyone aware of an unresolved bug or other reason to hold off
> > release of version 4.6.1?  If not, I will probably package it up
> > for release next weekend.
>  

=== qt ===
> Daniel J Sebald <dan...@ie...>
> Is Qt terminal in 4.6.1?  The only thing I can think of is supporting 
> Windows properly in Qt term, but no volunteers with a Windows machine 
> have stepped forward yet.

Qt was already added in 4.6.0.  4.6.1 will contain a few already-applied 
patches related to installation on OSX.  


=== emacs ===
> Mojca Miklavec <moj...@gm...>
> Not a major showstopper, but I would be grateful if someone could take
> a look at the attached patch for emacs (and apply before the release
> it if possible). The problem is that setting
>     EMACS=/path/to/some/Emacs ./configure
> is later "reset" with
>     EMACS=`basename $EMACS`
> in lisp/configure[.in], so version checking and all further
> emacs-related operation fail to work properly since they call whatever
> emacs/xemacs comes first in PATH instead of the one requested by user.

I am very reluctant to make changes to the configuration system for 4.6.1
that have not previously been tested in the development tree.  
That said, I am willing to have a look at this if you can you clarify 
what the problem actually is.

Which of these is happening?
1) you have an "emacs" in your path that is incapable of compiling the 
   three files gnuplot.elc gnuplot-gui.elc gnuplot-eldoc.elc?
2) The version check to see if emacs is older than version 20.3 fails?
3) The *.elc files are compiled properly but installed in the wrong
   site-lisp directory?

As to (2) is any of this still needed?  The README says that the 
info-look.xxx files are a work-around for incompatibilities in ancient
versions of emacs and Xemacs.  Can we just get rid of these files and
get rid of that section of the Makefile?  


=== Aquaterm ===
> Mojca Miklavec <moj...@gm...>
> I would be very very grateful if this patch could be applied:
> http://trac.macports.org/browser/trunk/dports/math/gnuplot/files/patch-configure-aquaterm.diff?rev=96897
> (only "configure.in", "m4/apple.m4" and the first line of "term/aquaterm.trm")
> --- configure.in.orig
> +++ configure.in
> @@ -1366,5 +1366,5 @@
>  
> -if test "$ac_cv_lib_aquaterm_aqtInit" = yes; then
> +if test "$with_aquaterm" = yes; then
>    AC_MSG_RESULT([  aqua terminal: yes])
>  else
>    AC_MSG_RESULT([  aqua terminal: no])
 
That change is not in the main branch. Are you sure it is needed?
 
> m4/apple.m4
This patch bears little resemblance to what is currently in 4.7.
Does the build system in 4.7 work, or not?  
If the 4.7 version does work, should I just copy it to 4.6?
If not, then please submit a patch against 4.7 rather than 4.6
and we'll work from there.

> term/aquaterm.trm
> --- term/aquaterm.trm.orig
> +++ term/aquaterm.trm
> @@ -94,3 +94,3 @@
>  #ifdef TERM_BODY
> -#import <aquaterm/AQTAdapter.h>
> +#import <AquaTerm/AQTAdapter.h>

OK.


=== BOOLEANS ===
> Mojca Miklavec <moj...@gm...>
> Definitions of BOOL are still problematic (and configuration is broken
> on Solaris, older Macs, ...).

My understanding of the situation on Solaris is that no single fix will
work for all versions of Solaris.  The versions differ from each other,
and the requirements for C++ reportedly conflict with those for C.
But I'm working from ignorance, relying on Solaris users to provide help.
I have 2 (3?) times previously applied patches that were submitted to
handle Bool on some version of Solaris, and each time people reported
that the change caused breakage on other systems.  So unless someone has
a patch that has been well tested on multiple versions of Solaris, 
I won't touch this.

It is of course unfortunate that the Solaris compilers have a problem
with standard C/C++ Booleans.  It is likewise unfortunate that MSVC isn't
ANSI-compliant with regard to initializing named fields in a structure,
and unfortunate that some platforms lack a usable version of snprintf(). 
We do try to accommodate in the source code where possible, but at some
point it's just not worth the effort.

Anyhow, this is clearly a long-term issue and not something that can
quickly be patched for 4.6.1.

	Ethan