bug-gnulib
[Top][All Lists]
Advanced

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

Re: threadlib and emacs


From: Bruno Haible
Subject: Re: threadlib and emacs
Date: Mon, 18 Jul 2011 00:10:40 +0200
User-agent: KMail/1.13.6 (Linux/2.6.37.6-0.5-desktop; KDE/4.6.0; x86_64; ; )

Hi Paul,

> Here are two proposed patches to get Emacs to work with gnulib
> pthread_sigmask.  The idea is that GNU Emacs will use --avoid=threadlib.
> 
> The first patch is for gnulib-tool, the second for pthread_sigmask;
> the second depends on the first.  The second patch is intended to
> change the behavior of the pthread_sigmask module only when threadlib is
> avoided.

There are two major problems with this proposal.

1) You are having a problem with the 'threadlib' module, and you try to
   fix that by modifying the modules that depend on this module. But
   there is not only the 'pthread_sigmask' module that depends on it,
   but also
     lock
     tls
     cond
     thread
     yield
     gettext
   This is a maintenance problem. It will make maintenance easier
   if you provide a replacement for 'threadlib' that obeys the same
   interface as threadlib (i.e. its m4 macros set the same AC_SUBSTed
   variables).

1b) I understand that the use of gl_AVOID_MODULE_x is to avoid a problem
of the previous approach: m4_ifdef([gl_THREADLIB], ...) did not work
because gettext had installed a copy of threadlib.m4 in $PREFIX/share/aclocal/.
But it still smells the workaround hack (it makes a semantic difference
between a module that is absent and a module that is avoided). It
is preferable to fix this issue by defining gl_THREADLIB yourself in
different .m4 file.

2) The major problem of your proposal is that the changes are ONLY useful
for Emacs. The special situation that you want to solve is that the variables
LIBS and CPPLAGS are fixed in emacs/configure.in. This is a "database of
options per platform" approach, the opposite approach than Autoconf. The
threadlib-that-does-not-change-CPPFLAGS is therefore only useful for Emacs.
I don't find it appropriate to commit such code in gnulib. Keep it in the
Emacs code repository, and ask from gnulib only the minimal changes that
allow such an override to work.

Given that you are using a gnulib-to-emacs integration process which allows
you to use local overrides, and that gnulib-tool also has an option --local-dir
that allows local overrides, you should be able to use one of these mechanisms.

As I already said, the packages gettext, libiconv, and libunistring each have
some gnulib overrides. The simple fact is, not all changes that are useful
for 1 package are useful for all packages that use gnulib.

3) Side note: Your patch made me think whether we need some magic in gnulib-tool
so that if --avoid=MODULE is passed _and_ a module file modules/avoided/MODULE
exists, that module file should be used instead of MODULE. But that is not
a big win, because the user is free to pass
   --avoid=MODULE avoided/MODULE
on the command line (adding avoided/MODULE instead of MODULE).

Bruno
--
In memoriam Jane Haining <http://en.wikipedia.org/wiki/Jane_Haining> 
<http://www.shoah.dk/Courage/Haining.htm>



reply via email to

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