23.0.50; Image support disabled by default?

23.0.50; Image support disabled by default?

[Yavor Doganov]

This change

2008-01-23  Tom Tromey  <tromey@redhat.com>

	* configure.in (OPTION_DEFAULT_ON, OPTION_DEFAULT_OFF): New
	macros.
	(EMACS_ARG_Y, EMACS_ARG_N): Remove.
	Update all users.

introduces a regression: if the user runs ./configure without
arguments, image support is disabled by default, so now one has to
explicitly specify the the various --with-foo options for all image
formats.

Was this intended or it happened by accident?  I imagine that the
majority of the users want support for as many image formats as
possible.

2008-01-23  Yavor Doganov  <yavor@gnu.org>  (tiny change)

	* configure.in: Use OPTION_DEFAULT_ON for xpm, jpeg, tiff, 
	gif, png and rsvg.

*** configure.in	23 яну 2008 12:04:23 +0200	1.497
--- configure.in	23 яну 2008 17:46:00 +0200	
***************
*** 122,134 ****
  	  with_x_toolkit=$val
  ])
  
! OPTION_DEFAULT_OFF([xpm],[use -lXpm for displaying XPM images])
! OPTION_DEFAULT_OFF([jpeg],[use -ljpeg for displaying JPEG images])
! OPTION_DEFAULT_OFF([tiff],[use -ltiff for displaying TIFF images])
! OPTION_DEFAULT_OFF([gif],[use -lgif (or -lungif) for displaying GIF images])
! OPTION_DEFAULT_OFF([png],[use -lpng for displaying PNG images])
  OPTION_DEFAULT_OFF([gpm],[use -lgpm for mouse support on a GNU/Linux console])
! OPTION_DEFAULT_OFF([rsvg],[use -lrsvg-2 for displaying SVG images])
  OPTION_DEFAULT_OFF([gtk],[use GTK (same as --with-x-toolkit=gtk)])
  OPTION_DEFAULT_ON([toolkit-scroll-bars],[don't use Motif or Xaw3d scroll bars])
  OPTION_DEFAULT_ON([xaw3d],[don't use Xaw3d])
--- 122,134 ----
  	  with_x_toolkit=$val
  ])
  
! OPTION_DEFAULT_ON([xpm],[use -lXpm for displaying XPM images])
! OPTION_DEFAULT_ON([jpeg],[use -ljpeg for displaying JPEG images])
! OPTION_DEFAULT_ON([tiff],[use -ltiff for displaying TIFF images])
! OPTION_DEFAULT_ON([gif],[use -lgif (or -lungif) for displaying GIF images])
! OPTION_DEFAULT_ON([png],[use -lpng for displaying PNG images])
  OPTION_DEFAULT_OFF([gpm],[use -lgpm for mouse support on a GNU/Linux console])
! OPTION_DEFAULT_ON([rsvg],[use -lrsvg-2 for displaying SVG images])
  OPTION_DEFAULT_OFF([gtk],[use GTK (same as --with-x-toolkit=gtk)])
  OPTION_DEFAULT_ON([toolkit-scroll-bars],[don't use Motif or Xaw3d scroll bars])
  OPTION_DEFAULT_ON([xaw3d],[don't use Xaw3d])

Re: 23.0.50; Image support disabled by default?

[Tom Tromey]

>>>>> "Yavor" == Yavor Doganov <yavor@gnu.org> writes:

Yavor> Was this intended or it happened by accident?  I imagine that the
Yavor> majority of the users want support for as many image formats as
Yavor> possible.

It was an accident.  Sorry about that, I overlooked how the variable
test were written in this case.

Yavor> 2008-01-23  Yavor Doganov  <yavor@gnu.org>  (tiny change)
Yavor> 	* configure.in: Use OPTION_DEFAULT_ON for xpm, jpeg, tiff, 
Yavor> 	gif, png and rsvg.

I think this should go in.

Tom

Re: 23.0.50; Image support disabled by default?

[Jason Rumney]

Yavor Doganov wrote:
> ! OPTION_DEFAULT_ON([xpm],[use -lXpm for displaying XPM images])
> ! OPTION_DEFAULT_ON([jpeg],[use -ljpeg for displaying JPEG images])
> ! OPTION_DEFAULT_ON([tiff],[use -ltiff for displaying TIFF images])
> ! OPTION_DEFAULT_ON([gif],[use -lgif (or -lungif) for displaying GIF images])
> ! OPTION_DEFAULT_ON([png],[use -lpng for displaying PNG images])
>   OPTION_DEFAULT_OFF([gpm],[use -lgpm for mouse support on a GNU/Linux console])
> ! OPTION_DEFAULT_ON([rsvg],[use -lrsvg-2 for displaying SVG images])
>   OPTION_DEFAULT_OFF([gtk],[use GTK (same as --with-x-toolkit=gtk)])
>   

Also GTK should be on by default. The whole change probably needs 
reviewing, as it seems to either be based on a very old version of 
configure.in or everything has been reversed.

Re: 23.0.50; Image support disabled by default?

[Yavor Doganov]

On Wed, Jan 23, 2008 at 05:17:39PM +0000, Jason Rumney wrote:
>>   OPTION_DEFAULT_OFF([gtk],[use GTK (same as --with-x-toolkit=gtk)])

> Also GTK should be on by default.

It is on by default now; the above line is a bit misleading.

Re: 23.0.50; Image support disabled by default?

[Tom Tromey]

>>>>> "Jason" == Jason Rumney <jasonr@gnu.org> writes:

Jason> Also GTK should be on by default. The whole change probably
Jason> needs reviewing, as it seems to either be based on a very old
Jason> version of configure.in or everything has been reversed.

It is more that I just messed up and didn't realize how much code was
checking `$with_foo != no' while using the ostensible "default to yes"
macro.

Tom

Re: 23.0.50; Image support disabled by default?

[Glenn Morris]

I tried to fix this. I'm still not convinced all the various options
have the same behaviour as they did before...


--with-gtk should not be of type ON by default, IMO, because it will
change behaviour. In order to get eg a Lucid toolkit, I'd have to use

   --with-gtk=no --with-x-toolkit=lucid

to avoid an error about incompatible options. Currently I can just
specify a toolkit.

The default X toolkit is still gtk, even without --with-gtk being ON.


In fact, as a separate issue I'd like to suggest getting rid of the
--with-gtk option. The --with-x-toolkit option on its own allows for
all the choices, AFAIK, in a simpler fashion. No need to have two ways
to specify the same thing.

Re: 23.0.50; Image support disabled by default?

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 24 Jan 2008 23:37:04 -0500, Glenn Morris <rgm@gnu.org> said:

> I tried to fix this. I'm still not convinced all the various options
> have the same behaviour as they did before...

Setting CC on configure no longer works without `--without-gcc'.

  CC='gcc -arch ppc64' ./configure --without-gcc

looks so strange.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: 23.0.50; Image support disabled by default?

[Glenn Morris]

YAMAMOTO Mitsuharu wrote:

> Setting CC on configure no longer works without `--without-gcc'.
>
>   CC='gcc -arch ppc64' ./configure --without-gcc
>
> looks so strange.

That's clearly broken. This new DEFAULT_ON/OFF stuff has removed the
possibility that not specifying an option might be different from
explicitly saying yes/no (respectively).

Re: 23.0.50; Image support disabled by default?

[Tom Tromey]

>>>>> "GM" == Glenn Morris <rgm@gnu.org> writes:

GM> YAMAMOTO Mitsuharu wrote:
>> Setting CC on configure no longer works without `--without-gcc'.
>> 
>> CC='gcc -arch ppc64' ./configure --without-gcc
>> 
>> looks so strange.

GM> That's clearly broken. This new DEFAULT_ON/OFF stuff has removed the
GM> possibility that not specifying an option might be different from
GM> explicitly saying yes/no (respectively).

I'm sorry about the breakage from this.
I will come up with a patch this weekend.

Tom

Re: 23.0.50; Image support disabled by default?

[Tom Tromey]

>>>>> ">" == YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

>> Setting CC on configure no longer works without `--without-gcc'.
>>   CC='gcc -arch ppc64' ./configure --without-gcc

I don't see a reason to have --without-gcc at all.  The normal
approach is to have the user set CC on the command line and then have
configure detect whether or not it is gcc; AC_PROG_CC will do this.

So what do you think of this?

Tom

ChangeLog:
2008-01-27  Tom Tromey  <tromey@redhat.com>

	* INSTALL (DETAILED BUILDING AND INSTALLATION): Remove
	--with-gcc.
	* configure.in (--with-gcc): Remove.

Index: INSTALL
===================================================================
RCS file: /sources/emacs/emacs/INSTALL,v
retrieving revision 1.126
diff -u -r1.126 INSTALL
--- INSTALL	8 Jan 2008 20:46:40 -0000	1.126
+++ INSTALL	27 Jan 2008 22:57:45 -0000
@@ -270,11 +270,6 @@
 PATH is the pathname to pkg-config.  Note that GTK version 2.4 or
 newer is required for Emacs.
 
-The `--with-gcc' option specifies that the build process should
-compile Emacs using GCC.  If you don't want to use GCC, specify
-`--with-gcc=no'.  If you omit this option, `configure' will search
-for GCC in your path, and use it if present.
-
 The Emacs mail reader RMAIL is configured to be able to read mail from
 a POP3 server by default.  Versions of the POP protocol older than
 POP3 are not supported.  For Kerberos-authenticated POP add
Index: configure.in
===================================================================
RCS file: /sources/emacs/emacs/configure.in,v
retrieving revision 1.502
diff -u -r1.502 configure.in
--- configure.in	27 Jan 2008 16:06:01 -0000	1.502
+++ configure.in	27 Jan 2008 22:57:46 -0000
@@ -70,11 +70,6 @@
    m4_bpatsubst([with_$1], [[^0-9a-z]], [_])=yes])dnl
 ])dnl
 
-dnl By default, neither off nor on.
-AC_ARG_WITH([gcc],
-[AS_HELP_STRING([--without-gcc],
-    [don't use GCC to compile Emacs even if GCC is found])])
-
 OPTION_DEFAULT_ON([pop],[don't support POP mail retrieval with movemail])
 if test "$with_pop" = yes; then
    AC_DEFINE(MAIL_USE_POP)
@@ -817,11 +812,6 @@
 # Save the value of CFLAGS that the user specified.
 SPECIFIED_CFLAGS="$CFLAGS"
 
-case ${with_gcc} in
-  "yes" ) CC="gcc" GCC=yes ;;
-  "no"  ) : ${CC=cc} ;;
-  * )
-esac
 AC_PROG_CC
 
 # On Suns, sometimes $CPP names a directory.

Re: 23.0.50; Image support disabled by default?

[Tom Tromey]

Tom> I'm sorry about the breakage from this.
Tom> I will come up with a patch this weekend.

I looked at all the recent configure-related bug reports, but it
appears that Glenn Morris already fixed them all.  Thanks, Glenn.

Tom

Removing --with-gcc, Cygwin [was Re: 23.0.50; Image support disabled by default?]

[Glenn Morris]

Tom Tromey wrote:

> I don't see a reason to have --without-gcc at all.  The normal
> approach is to have the user set CC on the command line and then have
> configure detect whether or not it is gcc; AC_PROG_CC will do this.

[patch elided]

Sounds fine to me.

etc/PROBLEMS and nt/INSTALL both suggest using '--with-gcc' (plus
other stuff) for some Cygwin builds.

Does Cygwin actually need --with-gcc for some reason, or is it ok to
remove it?

Removing --with-gtk [was Re: 23.0.50; Image support disabled by default?]

[Glenn Morris]

If there are no objections, I propose to remove the configure option
--with-gtk. It's not necessary, because: i) gtk is the default now;
and ii) --with-x-toolkit=gtk has the same meaning, and there's no need
to have two ways to say the same thing.


Glenn Morris wrote:

> In fact, as a separate issue I'd like to suggest getting rid of the
> --with-gtk option. The --with-x-toolkit option on its own allows for
> all the choices, AFAIK, in a simpler fashion. No need to have two ways
> to specify the same thing.

Re: Removing --with-gcc, Cygwin [was Re: 23.0.50; Image support disabled by default?]

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Date: Sat, 02 Feb 2008 17:32:07 -0500
> Cc: Yavor Doganov <yavor@gnu.org>, Jason Rumney <jasonr@gnu.org>,
> 	YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>, emacs-devel@gnu.org
> 
> etc/PROBLEMS and nt/INSTALL both suggest using '--with-gcc' (plus
> other stuff) for some Cygwin builds.

nt/INSTALL is not relevant to Cygwin builds.

Re: Removing --with-gcc, Cygwin

[Glenn Morris]

Eli Zaretskii wrote:

> nt/INSTALL is not relevant to Cygwin builds.

My total ignorance of such issues is what prompted my question.
It certainly seems to be related to Cygwin to me:


   If you are using certain Cygwin builds of GCC, such as Cygwin
   version 1.1.8, you may need to specify some extra compiler flags like so:
  
     configure --with-gcc --cflags -mwin32 --cflags -D__MSVCRT__
       --ldflags -mwin32
  
   However, the latest Cygwin versions, such as 1.3.3, don't need
   those switches; you can simply use "configure --with-gcc".

Re: Removing --with-gcc, Cygwin

[Glenn Morris]

Glenn Morris wrote:

nt/INSTALL:

>      configure --with-gcc --cflags -mwin32 --cflags -D__MSVCRT__
>        --ldflags -mwin32

Oh, I guess this `configure' actually `configure.bat', which has its
own --with-gcc option...?

Re: Removing --with-gcc, Cygwin

[Jason Rumney]

Glenn Morris wrote:
> Glenn Morris wrote:
>
> nt/INSTALL:
>
>   
>>      configure --with-gcc --cflags -mwin32 --cflags -D__MSVCRT__
>>        --ldflags -mwin32
>>     
>
> Oh, I guess this `configure' actually `configure.bat', which has its
> own --with-gcc option...?
>   

Yes, although --with-gcc is the default, so it is not needed there either.

Re: Removing --with-gcc, Cygwin

[David Robinow]

On Feb 3, 2008 4:24 PM, Jason Rumney <jasonr@gnu.org> wrote:
>
> Glenn Morris wrote:
> > Oh, I guess this `configure' actually `configure.bat', which has its
> > own --with-gcc option...?
> >
>
> Yes, although --with-gcc is the default, so it is not needed there either.
 Actually, msvc is used if it is found. If both are present,
--with-gcc is needed to force use of gcc.

Re: Removing --with-gcc, Cygwin

[Jason Rumney]

David Robinow wrote:
>  Actually, msvc is used if it is found. If both are present,
> --with-gcc is needed to force use of gcc.
>   

So it is. I thought it was changed years ago. I have fixed that now.

Re: Removing --with-gcc, Cygwin

[Angelo Graziosi]

Glenn Morris wrote:

 > However, the latest Cygwin versions, such as 1.3.3,
                                                ^^^^^^

But 1.3.3 is very very old and not supported any more!

The last version is 1.5.25-7 and the next will be 1.7!

Cheers,
    Angelo.

Re: Removing --with-gcc, Cygwin

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: tromey@redhat.com,  yavor@gnu.org,  jasonr@gnu.org,  mituharu@math.s.chiba-u.ac.jp,  emacs-devel@gnu.org
> Date: Sun, 03 Feb 2008 16:00:42 -0500
> 
> Eli Zaretskii wrote:
> 
> > nt/INSTALL is not relevant to Cygwin builds.
> 
> My total ignorance of such issues is what prompted my question.
> It certainly seems to be related to Cygwin to me:
> 
> 
>    If you are using certain Cygwin builds of GCC, such as Cygwin
>    version 1.1.8, you may need to specify some extra compiler flags like so:
>   
>      configure --with-gcc --cflags -mwin32 --cflags -D__MSVCRT__
>        --ldflags -mwin32
>   
>    However, the latest Cygwin versions, such as 1.3.3, don't need
>    those switches; you can simply use "configure --with-gcc".

This talks about Cygwin builds of GCC, not of Emacs.  The switches
mentioned above let Cygwin GCC produce native Windows executables (as
opposed to Cygwin executables, which depend on Cygwin runtime
support).