new image library "requirements"

new image library "requirements"

[Miles Bader]

I just tried compiling a new emacs, and the configure failed with:

   configure: error: The following required libraries was not found:
        libgif/libungif libtiff
   Maybe some development libraries/packages are missing?
   If you don't want to link with them give
        --with-gif=no --with-tiff=no
   as options to configure

While there's a case to be made for "requiring" (without options) X
libraries or even jpeg /png, I think requiring these is kind of silly.

Tiff is fairly rarely used except in specialized applications.

The case with .gif is more vague, but it seems largely a legacy format,
and is getting more and more rare these days -- you see it on old web
sites, and people still use it for "animated" images (which emacs
doesn't support), but it seems kind of unusual to see it for the kind of
content which people might keep around.

At the least, I'd drop the "requirement" for tiff.

-miles
-- 
Run away!  Run away!

Re: new image library "requirements"

[Jan Djärv]

Miles Bader skrev:
> I just tried compiling a new emacs, and the configure failed with:
> 
>    configure: error: The following required libraries was not found:
>         libgif/libungif libtiff
>    Maybe some development libraries/packages are missing?
>    If you don't want to link with them give
>         --with-gif=no --with-tiff=no
>    as options to configure
> 
> While there's a case to be made for "requiring" (without options) X
> libraries or even jpeg /png, I think requiring these is kind of silly.
> 
> Tiff is fairly rarely used except in specialized applications.
> 
> The case with .gif is more vague, but it seems largely a legacy format,
> and is getting more and more rare these days -- you see it on old web
> sites, and people still use it for "animated" images (which emacs
> doesn't support), but it seems kind of unusual to see it for the kind of
> content which people might keep around.
> 
> At the least, I'd drop the "requirement" for tiff.
> 

I asked the same thing, but David Kastrup was the only one who commented 
(granted, the subject line was not about image libraries):

> It is quite common in prepress, and since Emacs includes stuff like
> image-dired, it would appear reasonable to not omit it without notice.

	Jan D.

Re: new image library "requirements"

[Nick Roberts]

 > > While there's a case to be made for "requiring" (without options) X
 > > libraries or even jpeg /png, I think requiring these is kind of silly.
 > > 
 > > Tiff is fairly rarely used except in specialized applications.
 > > 
 > > The case with .gif is more vague, but it seems largely a legacy format,
 > > and is getting more and more rare these days -- you see it on old web
 > > sites, and people still use it for "animated" images (which emacs
 > > doesn't support), but it seems kind of unusual to see it for the kind of
 > > content which people might keep around.
 > > 
 > > At the least, I'd drop the "requirement" for tiff.
 > > 
 > 
 > I asked the same thing, but David Kastrup was the only one who commented 
 > (granted, the subject line was not about image libraries):

Yes, where does it all end?  Emacs will build without alsa headers but
presumably that leads to some loss of functionality (playing midi files,
maybe?).  Should configure throw an error when these aren't found?

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: new image library "requirements"

[David Kastrup]

Jan Djärv <jan.h.d@swipnet.se> writes:

> Miles Bader skrev:
>> I just tried compiling a new emacs, and the configure failed with:
>>
>>    configure: error: The following required libraries was not found:
>>         libgif/libungif libtiff
>>    Maybe some development libraries/packages are missing?
>>    If you don't want to link with them give
>>         --with-gif=no --with-tiff=no
>>    as options to configure
>>
>> While there's a case to be made for "requiring" (without options) X
>> libraries or even jpeg /png, I think requiring these is kind of silly.
>>
>> Tiff is fairly rarely used except in specialized applications.

Disagree: it is the dominant format for CMYK work.

>> The case with .gif is more vague, but it seems largely a legacy
>> format, and is getting more and more rare these days -- you see it
>> on old web sites, and people still use it for "animated" images
>> (which emacs doesn't support), but it seems kind of unusual to see
>> it for the kind of content which people might keep around.

Disagree: gifs still outnumber png files about 3:1 at least on the
web.

>> At the least, I'd drop the "requirement" for tiff.
>
> I asked the same thing, but David Kastrup was the only one who
> commented (granted, the subject line was not about image libraries):
>
>> It is quite common in prepress, and since Emacs includes stuff like
>> image-dired, it would appear reasonable to not omit it without
>> notice.

The idea behind the requirements was to not get the user an Emacs
version that does not have full capabilities without notice.  Since
image browsing is a part of Emacs, I feel that this is appropriate.
One could turn it into a very strong worded and visible warning
instead, possibly.

But the previous behavior of being somewhere in a yes-and-no summary
list (among items for which "no" does not imply a loss of
functionality, like for a particular memory allocation scheme) is not
likely to get the user to realize what happens.

-- 
David Kastrup

Re: new image library "requirements"

[David Kastrup]

Nick Roberts <nickrob@snap.net.nz> writes:

>  > > While there's a case to be made for "requiring" (without options) X
>  > > libraries or even jpeg /png, I think requiring these is kind of silly.
>  > > 
>  > > Tiff is fairly rarely used except in specialized applications.
>  > > 
>  > > The case with .gif is more vague, but it seems largely a legacy format,
>  > > and is getting more and more rare these days -- you see it on old web
>  > > sites, and people still use it for "animated" images (which emacs
>  > > doesn't support), but it seems kind of unusual to see it for the kind of
>  > > content which people might keep around.
>  > > 
>  > > At the least, I'd drop the "requirement" for tiff.
>  > > 
>  > 
>  > I asked the same thing, but David Kastrup was the only one who commented 
>  > (granted, the subject line was not about image libraries):
>
> Yes, where does it all end?  Emacs will build without alsa headers but
> presumably that leads to some loss of functionality (playing midi files,
> maybe?).  Should configure throw an error when these aren't found?

Maybe it should make a human-understandable report of missing
functionality at the very end of the configure run:

----  WARNING ----
The following functionalities will be missing in your compilation of
Emacs because of missing development libraries (specify
-without-FEATURE to omit warning about such a missing feature):

jpeg: used for displaying jpeg image files
tiff: used for displaying tiff image files
xpm: used for displaying xpm image files and color icons
alsa: used for playing sounds from within Emacs

-- 
David Kastrup

Re: new image library "requirements"

[martin rudalics]

 > Maybe it should make a human-understandable report of missing
 > functionality at the very end of the configure run:

I support that.

 >
 > ----  WARNING ----
 > The following functionalities will be missing in your compilation of
 > Emacs because of missing development libraries (specify
 > -without-FEATURE to omit warning about such a missing feature):
 >
 > jpeg: used for displaying jpeg image files
 > tiff: used for displaying tiff image files
 > xpm: used for displaying xpm image files and color icons
 > alsa: used for playing sounds from within Emacs

Including a short description of the consequences when such a
functionality is missing.

Re: new image library "requirements"

[Sascha Wilde]

martin rudalics <rudalics@gmx.at> wrote:

>> Maybe it should make a human-understandable report of missing
>> functionality at the very end of the configure run:
>
> I support that.

+1

>> ----  WARNING ----
>> The following functionalities will be missing in your compilation of
>> Emacs because of missing development libraries (specify
>> -without-FEATURE to omit warning about such a missing feature):
>>
>> jpeg: used for displaying jpeg image files
>> tiff: used for displaying tiff image files
>> xpm: used for displaying xpm image files and color icons
>> alsa: used for playing sounds from within Emacs
>
> Including a short description of the consequences when such a
> functionality is missing.

Please don't make this unnecessary verbose.  I think "The following
functionalities will be missing ... displaying jpeg image files"
perfectly clear.  People building complex software like emacs from
source should be able to understand this messages and its
consequences.

sascha
-- 
Sascha Wilde
"The primary difference [...] is that the Java program will reliably
and obviously crash, whereas the C program will do something obscure."  
   -- Java Language Tutorial

Re: new image library "requirements"

[Lennart Borgman (gmail)]

Sascha Wilde wrote:
>>> ----  WARNING ----
>>> The following functionalities will be missing in your compilation of
>>> Emacs because of missing development libraries (specify
>>> -without-FEATURE to omit warning about such a missing feature):
>>>
>>> jpeg: used for displaying jpeg image files
>>> tiff: used for displaying tiff image files
>>> xpm: used for displaying xpm image files and color icons
>>> alsa: used for playing sounds from within Emacs
>> Including a short description of the consequences when such a
>> functionality is missing.
> 
> Please don't make this unnecessary verbose.  I think "The following
> functionalities will be missing ... displaying jpeg image files"
> perfectly clear.  People building complex software like emacs from
> source should be able to understand this messages and its
> consequences.

Point to some documentation.

Re: new image library "requirements"

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Mon, 18 Jun 2007 09:34:59 +0200
> Cc: Miles Bader <miles@gnu.org>,
> 	Jan =?iso-8859-1?Q?Dj=E4rv?= <jan.h.d@swipnet.se>, emacs-devel@gnu.org
> 
> Maybe it should make a human-understandable report of missing
> functionality at the very end of the configure run:
> 
> ----  WARNING ----
> The following functionalities will be missing in your compilation of
> Emacs because of missing development libraries (specify
> -without-FEATURE to omit warning about such a missing feature):
> 
> jpeg: used for displaying jpeg image files
> tiff: used for displaying tiff image files
> xpm: used for displaying xpm image files and color icons
> alsa: used for playing sounds from within Emacs

Either that (we already do something similar for X toolkits and such
likes), or display a warning at startup (or both).

But failing the configure script is too draconian, IMHO.

Re: new image library "requirements"

[Jan Djärv]

Eli Zaretskii skrev:
>> From: David Kastrup <dak@gnu.org>
>> Date: Mon, 18 Jun 2007 09:34:59 +0200
>> Cc: Miles Bader <miles@gnu.org>,
>> 	Jan =?iso-8859-1?Q?Dj=E4rv?= <jan.h.d@swipnet.se>, emacs-devel@gnu.org
>>
>> Maybe it should make a human-understandable report of missing
>> functionality at the very end of the configure run:
>>
>> ----  WARNING ----
>> The following functionalities will be missing in your compilation of
>> Emacs because of missing development libraries (specify
>> -without-FEATURE to omit warning about such a missing feature):
>>
>> jpeg: used for displaying jpeg image files
>> tiff: used for displaying tiff image files
>> xpm: used for displaying xpm image files and color icons
>> alsa: used for playing sounds from within Emacs
> 
> Either that (we already do something similar for X toolkits and such
> likes), or display a warning at startup (or both).
> 
> But failing the configure script is too draconian, IMHO.

That was Richards call:

> If we know enough to give a specific message with specific advice,
> that is better than an error from ld.  But it should be a fatal error,
> not a mere warning.  It should make the user fix things and try again.

	Jan D.

Re: new image library "requirements"

[Eli Zaretskii]

> Date: Tue, 19 Jun 2007 07:54:00 +0200
> From: =?ISO-8859-1?Q?Jan_Dj=E4rv?= <jan.h.d@swipnet.se>
> Cc: emacs-devel@gnu.org
> 
> > But failing the configure script is too draconian, IMHO.
> 
> That was Richards call:

Well, I know, but I still think it's draconian.

Re: new image library "requirements"

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Tue, 19 Jun 2007 07:54:00 +0200
>> From: =?ISO-8859-1?Q?Jan_Dj=E4rv?= <jan.h.d@swipnet.se>
>> Cc: emacs-devel@gnu.org
>> 
>> > But failing the configure script is too draconian, IMHO.
>> 
>> That was Richards call:
>
> Well, I know, but I still think it's draconian.

Well, the previous behavior was too lax: it led to frequent problem
reports.  Perhaps we'll figure out something as effective as the
Draconian approach without a similar annoyance level.

Maybe we could add something like an overall --without-panic option
that will not abort unless nothing useful can be compiled?  That would
be more convenient for people than having to switch off every library
manually if they know what they are doing.

-- 
David Kastrup

Re: new image library "requirements"

[Jason Rumney]

David Kastrup wrote:
> Well, the previous behavior was too lax: it led to frequent problem
> reports.  Perhaps we'll figure out something as effective as the
> Draconian approach without a similar annoyance level.
>   

Whether configure aborts or not, I think we should print a summary of
the problems at the end of the configure script.  In the case where we
abort, it should mention the --without-* options the user could use to
configure Emacs with their current set of libraries.

Re: new image library "requirements"

[Richard Stallman]

    > Yes, where does it all end?  Emacs will build without alsa headers but
    > presumably that leads to some loss of functionality (playing midi files,
    > maybe?).  Should configure throw an error when these aren't found?

The answer to that question isn't a theoretical one.  It is a matter
of how important a given feature is as a feature of Emacs.

For instance, for sound: how important a problem is it that people
build Emacs and don't get sound, just because they didn't have the
right headers installed?  On the other side, how big an inconvenience
is it to be pressured into installing the headers, when you didn't
want sound anyway?

Re: new image library "requirements"

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     > Yes, where does it all end?  Emacs will build without alsa headers but
>     > presumably that leads to some loss of functionality (playing midi files,
>     > maybe?).  Should configure throw an error when these aren't found?
>
> The answer to that question isn't a theoretical one.  It is a matter
> of how important a given feature is as a feature of Emacs.
>
> For instance, for sound: how important a problem is it that people
> build Emacs and don't get sound, just because they didn't have the
> right headers installed?  On the other side, how big an
> inconvenience is it to be pressured into installing the headers,
> when you didn't want sound anyway?

We want to avoid having "underfeatured" Emacs binaries around without
people noticing: particularly bad track records have missing X11
support and missing XPM support (needed for color icons).

Requiring explicit options for suppressing such libraries (even if it
is just --without-panic) will mean that the output of
system-configuration-options (which is reported by report-emacs-bug)
will reflect this compilation configuration.  This makes error
diagnosis easier and provides a first pointer to the user before
actually sending the bug report.

When the user is not identical with the person compiling Emacs, this
might be even more relevant, though in all fairness, I think most of
the problems reported in this context have been from users making
their own compilations.

-- 
David Kastrup

Re: new image library "requirements"

[Nick Roberts]

 >     > Yes, where does it all end?  Emacs will build without alsa headers but
 >     > presumably that leads to some loss of functionality (playing midi
 >     > files, maybe?).  Should configure throw an error when these aren't
 >     > found?
 > 
 > The answer to that question isn't a theoretical one.  It is a matter
 > of how important a given feature is as a feature of Emacs.
 >
 > For instance, for sound: how important a problem is it that people
 > build Emacs and don't get sound, just because they didn't have the
 > right headers installed?  

I think lack of alsa headers leads to reduced sound functionality, not no
sound (oss gets used?).

 >                           On the other side, how big an inconvenience
 > is it to be pressured into installing the headers, when you didn't
 > want sound anyway?

But presumably this isn't a one size fits all problem but depends on what the
user intends to do with Emacs.  If configure just informs the user of what
functionality will be missing (rather than what libraries are missing), *he*
can decide, not us, if that is a problem or not.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: new image library "requirements"

[Jan Djärv]

Nick Roberts skrev:

> But presumably this isn't a one size fits all problem but depends on what the
> user intends to do with Emacs.  If configure just informs the user of what
> functionality will be missing (rather than what libraries are missing), *he*
> can decide, not us, if that is a problem or not.

He still can decide, just pass the relevant --without-xxx to configure.

	Jan D.

Re: new image library "requirements"

[Nick Roberts]

 > > But presumably this isn't a one size fits all problem but depends on what
 > > the user intends to do with Emacs.  If configure just informs the user of
 > > what functionality will be missing (rather than what libraries are
 > > missing), *he* can decide, not us, if that is a problem or not.
 > 
 > He still can decide, just pass the relevant --without-xxx to configure.

Yes but not without inconvenience.  If he doesn't want images and hasn't got
the headers for gif, tiff or png then configure presumably aborts three
times until he finally uses:

configure --without-gif --without-tiff --without-png

and then he has to go through all of it again if later he wishes to configure
with different options, e.g., CFLAGS=-g .

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: new image library "requirements"

[Richard Stallman]

    > jpeg: used for displaying jpeg image files
    > tiff: used for displaying tiff image files
    > xpm: used for displaying xpm image files and color icons
    > alsa: used for playing sounds from within Emacs

    Either that (we already do something similar for X toolkits and such
    likes), or display a warning at startup (or both).

Don't do that -- it would be a change for the worse.
An error message is the right thing when a crucial feature
that ought to work would fail due to missing headers.

Re: new image library "requirements"

[Richard Stallman]

    Maybe we could add something like an overall --without-panic option
    that will not abort unless nothing useful can be compiled?  That would
    be more convenient for people than having to switch off every library
    manually if they know what they are doing.

I don't object to this, but I think that having the executables
for Xlib or the toolkit and failing to have the development packages
will usually be an error rather than a choice.

Re: new image library "requirements"

[Stefan Monnier]

>> jpeg: used for displaying jpeg image files
>> tiff: used for displaying tiff image files
>> xpm: used for displaying xpm image files and color icons
>> alsa: used for playing sounds from within Emacs

>     Either that (we already do something similar for X toolkits and such
>     likes), or display a warning at startup (or both).

> Don't do that -- it would be a change for the worse.
> An error message is the right thing when a crucial feature
> that ought to work would fail due to missing headers.

tiff support is really not crucial in my book, and neither is alsa (I don't
even know of any package that makes use of it).


        Stefan

Re: new image library "requirements"

[Stefan Monnier]

> I don't object to this, but I think that having the executables
> for Xlib or the toolkit and failing to have the development packages
> will usually be an error rather than a choice.

Agreed.


        Stefan

Re: new image library "requirements"

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> CC: dak@gnu.org, emacs-devel@gnu.org
> Date: Tue, 19 Jun 2007 18:26:00 -0400
> 
> An error message is the right thing when a crucial feature
> that ought to work would fail due to missing headers.

How is the case of image libraries different from the X headers and
libraries?  Currently, if X headers and/or libraries were not found
by the configure script, we just print this in the summary at the end
of configure, and continue as if --without-x was specified.  Are you
saying that X support is less crucial than image support?

Re: new image library "requirements"

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Richard Stallman <rms@gnu.org>
>> CC: dak@gnu.org, emacs-devel@gnu.org
>> Date: Tue, 19 Jun 2007 18:26:00 -0400
>> 
>> An error message is the right thing when a crucial feature
>> that ought to work would fail due to missing headers.
>
> How is the case of image libraries different from the X headers and
> libraries?  Currently, if X headers and/or libraries were not found
> by the configure script, we just print this in the summary at the end
> of configure, and continue as if --without-x was specified.  Are you
> saying that X support is less crucial than image support?

It goes without saying that the same holds for X, and in fact there
have been proposals for what check to use here.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: new image library "requirements"

[Jan Djärv]

Nick Roberts skrev:
>  > > But presumably this isn't a one size fits all problem but depends on what
>  > > the user intends to do with Emacs.  If configure just informs the user of
>  > > what functionality will be missing (rather than what libraries are
>  > > missing), *he* can decide, not us, if that is a problem or not.
>  > 
>  > He still can decide, just pass the relevant --without-xxx to configure.
> 
> Yes but not without inconvenience.  If he doesn't want images and hasn't got
> the headers for gif, tiff or png then configure presumably aborts three
> times until he finally uses:
> 
> configure --without-gif --without-tiff --without-png
> 
> and then he has to go through all of it again if later he wishes to configure
> with different options, e.g., CFLAGS=-g .
> 

No, it aborts once and spells out the options to use so they can be copy and 
pasted.

	Jan D.

Re: new image library "requirements"

[Jan Djärv]

Eli Zaretskii skrev:
>> From: Richard Stallman <rms@gnu.org>
>> CC: dak@gnu.org, emacs-devel@gnu.org
>> Date: Tue, 19 Jun 2007 18:26:00 -0400
>>
>> An error message is the right thing when a crucial feature
>> that ought to work would fail due to missing headers.
> 
> How is the case of image libraries different from the X headers and
> libraries?  Currently, if X headers and/or libraries were not found
> by the configure script, we just print this in the summary at the end
> of configure, and continue as if --without-x was specified.  Are you
> saying that X support is less crucial than image support?


X development libraries are required before we even look for these image 
libraries.  There is no such thing as image support without X, except for W32 
and OSX, and those platforms don't use the image libraries we check for.

As stated earlier, it is probably a mistake to compile for X without image 
support.  Also, as has been said before, it is hard to look for X support if 
the development libraries for X is missing, even if we use the heuristic 
posted by David Kastrup.  Crosscompiling is one problem.

	Jan D.

Re: new image library "requirements"

[David Kastrup]

Jan Djärv <jan.h.d@swipnet.se> writes:

> X development libraries are required before we even look for these
> image libraries.  There is no such thing as image support without X,
> except for W32 and OSX, and those platforms don't use the image
> libraries we check for.
>
> As stated earlier, it is probably a mistake to compile for X without
> image support.  Also, as has been said before, it is hard to look for
> X support if the development libraries for X is missing, even if we
> use the heuristic posted by David Kastrup.  Crosscompiling is one
> problem.

People who do crosscompilation are _required_ to have a clue about the
difference of development libraries and system libraries.  No need
pampering for them, even though something more explicit like the
previous Yes/No list might be worthwhile.

The people we have to be concerned with are native compilers, those
that start with a tarball in order to arrive at a working Emacs on
their current system.

-- 
David Kastrup

Re: new image library "requirements"

[Glenn Morris]

David Kastrup wrote:

> The people we have to be concerned with are native compilers,[...]

ITYM "naive compilers". ;)

Re: new image library "requirements"

[Richard Stallman]

    Yes but not without inconvenience.  If he doesn't want images and hasn't got
    the headers for gif, tiff or png then configure presumably aborts three
    times until he finally uses:

    configure --without-gif --without-tiff --without-png

I agree with the proposal to indicate all such errors together, not
just the first one encountered.  That way he just needs two tries to
get it to configure right.

Re: new image library "requirements"

[Richard Stallman]

    tiff support is really not crucial in my book,

I've made the decision about that question.

Re: new image library "requirements"

[Richard Stallman]

    How is the case of image libraries different from the X headers and
    libraries?

They are similar cases and should be handled the same way.  Currently
the image libs are handled right, and the X headers are handled wrong.

		Currently, if X headers and/or libraries were not found
    by the configure script, we just print this in the summary at the end
    of configure, and continue as if --without-x was specified.

I already asked people to change that.
Would someone please change that, then ack?

Re: new image library "requirements"

[Jan Djärv]

Richard Stallman skrev:
>     How is the case of image libraries different from the X headers and
>     libraries?
> 
> They are similar cases and should be handled the same way.  Currently
> the image libs are handled right, and the X headers are handled wrong.
> 
> 		Currently, if X headers and/or libraries were not found
>     by the configure script, we just print this in the summary at the end
>     of configure, and continue as if --without-x was specified.
> 
> I already asked people to change that.
> Would someone please change that, then ack?

Ack.

	Jan D.

Re: new image library "requirements"

[Jason Rumney]

Jan Djärv wrote:
> X development libraries are required before we even look for these
> image libraries.  There is no such thing as image support without X,
> except for W32 and OSX, and those platforms don't use the image
> libraries we check for.
W32 does use the same libraries. I have just added the checks to
nt/configure.bat in the trunk. I notice no changes have been made yet to
the 22 branch, so I haven't made the changes there, but I think if this
change is going to reduce bug reports, we should make it in the branch also.

Re: new image library "requirements"

[Richard Stallman]

Thanks for fixing the handling of missing X development libraries.