bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Paul Eggert
Subject: bug#17289: 24.4.50; Build failure (Fedora 20)
Date: Sat, 19 Apr 2014 10:58:24 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0

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.

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]