Re: threadlib and emacs

[Bruno Haible]

Hi Paul,

> I looked at the current non-threadlib implementation again in the light of 
> your
> comments, and I now think that it goes too far, as it fusses with
> LIBS and so forth.  I'd rather have something even simpler.
> 
> I see that you're now working in that area, but
> once things have settled down, I'd like to essay something that
> just tries a POSIX.1-2008 signature without messing with
> compiler or linker flags, and gives up if that doesn't work.

Given the way emacs/configure.in works - it determines the CPPFLAGS and
LIBS up-front -, this makes a lot of sense for Emacs. But only for
Emacs, because the approach that emacs/configure.in uses (enumeration
of each supported platform) is the opposite of autoconfiguration.

gnulib has a mechanism by which a package can override parts of gnulib.
It's the --local-dir mechanism. I'm using it in each of libiconv,
gettext, and libunistring - although these packages have a more modern
autoconfigury than Emacs.

So the solution that I would propose is that you add to
emacs/gnulib-local a file m4/threadlib.m4 that overrides gnulib's
m4/threadlib.m4.
  - gl_THREADLIB_EARLY expands to empty, does not modify CPPFLAGS.
  - gl_THREADLIB_BODY sets gl_threads_api to either 'none' or
    'posix' (or 'win32' if that makes sense). It also defines at
    most one of the macros USE_POSIX_THREADS, USE_WIN32_THREADS.
    It sets the variables LIBTHREAD, LTLIBTHREAD, LIBMULTITHREAD,
    LTLIBMULTITHREAD to empty (on the assumptions that $LIBS already
    contains everything that's needed).
  - gl_THREADLIB does an AC_REQUIRE([gl_THREADLIB_BODY]).

Then we can make 'pthread_sigmask' and other modules depend on 'threadlib',
without having to special-case Emacs in each of them.

Does that sound feasible?

Bruno
-- 
In memoriam Jean Moulin <http://en.wikipedia.org/wiki/Jean_Moulin>