bug#17289: 24.4.50; Build failure (Fedora 20)

[Jan Djärv]

Hello.

19 apr 2014 kl. 19:58 skrev Paul Eggert <eggert@cs.ucla.edu>:

> Jan D. wrote:
> 
>> I though the point was to let CFLAGS
>> and LIBS to accumulate so we can catch conflicts early.  If for example,
>> Glib and librsvg has a conflict, it would be caught at configure time,
>> probably by ignoring one of the libs, and still let Emacs be built.
> 
> That may have been the point originally, but 'configure' long ago lost it; 
> even in emacs-24 libraries sometimes accumulate and sometimes do not.
> 
> The emacs-24 approach has a different problem: because some libraries 
> accumulate, later tests report answers that are incorrect for non-Emacs 
> applications such as etags which do not necessarily link to these libraries.  
> I ran into one of these problems with IRIX, and installed a small 
> hack-atop-a-hack in emacs-24 to fix that one little problem, but in the trunk 
> I am looking for a cleaner solution.  The basic idea is that each test should 
> be try to be independent from the others, and that any necessary dependencies 
> be indicated for the test.

That does not prevent configure from collecting all cflags/libs.
This can be done in some other variable.  That would be cleaner, because the 
solution you
have made now requires the Glib test to know just about everything that 
configure has done.
This is a really bad solution.  Adding another third party library now requires 
the Glib test to be updated as well.  Locality is broken.

> 
> I had tested the trunk change myself, but I can't easily test all possible 
> configuration options and so hadn't run into the reported failure.

I think just having Gtk+ and running configure without any parameters gives you 
this error.
Hardly a strange configuration, but probably the most used one.

>  Thanks Mattia for reporting it.  I fixed the bug in trunk bzr 116992, by 
> having the glib test mention its dependencies, and am marking the bug report 
> as done.
> 
> I'm puzzled, though, as to why glib is treated differently from the other 
> libraries.  Currently, Emacs uses glib if glib happens to be dragged in along 
> with some other library, and avoids glib otherwise. Why not just use glib if 
> available?  That would be simpler, no?

Some third party libaries use Glib, without Emacs explicitly using Glib itself.
Some older versions of the same libraries (or prehaps even the same version, 
but compiled differently) may not use Glib.  So we check if Glib is used.  It 
may be available, but Emacs and its third party library dependencies may not 
need it.

We do not want Emacs to require Glib, or link with it if it is not being used.

        Jan D.