GNU bug report logs - #32194
[PATCH] Use Gnulib regex for lib-src

Previous Next

Full log

View this message in rfc822 format

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 32194 <at> debbugs.gnu.org
Subject: bug#32194: [PATCH] Use Gnulib regex for lib-src
Date: Tue, 31 Jul 2018 11:21:38 -0700

[Message part 1 (text/plain, inline)]

Eli Zaretskii wrote:

> would it be possible to let the configure
>     script also check -lregex for those functions?  This could be
>     important on non-glibc systems.

It would no doubt be possible. However, we haven't found a need in other 
applications that use Gnulib. Gnulib code tends to be more up-to-date 
than system-supplied libraries, and in practice it's OK if the system 
puts the regex code in a place where 'configure' won't find it, as Emacs 
will just fall back on the better Gnulib version in that case.

> 2. Do we really need to rename src/regex.c?  We could have 2 regex.c in
>     separate directories, couldn't we?  If possible, I'd prefer not to
>     rename files, as that makes VCS forensics more complicated.

Renaming src/regex.h works around problems with having two include files 
src/regex.h and lib/regex.h that fight each other. I tried not renaming 
src/regex.h at first, and then ran into problems and gave up; although I 
surely could get it to work eventually, I figured that we'd continue to 
have ongoing problems and so it would be better to bite the bullet.

We could rename only src/regex.c, but it would be confusing for the .c 
and .h files to disagree in names. Also, having two different */regex.c 
files in different places would mean for long-term confusion by builders 
and bug-reporters.

Also, the regex code will surely change quite a bit once we decouple it 
from glibc, which lessens the advantage of trying to use 'git diff' on 
the result. Come to think of it, we might as well do some of the obvious 
simplifications now; I'll attach them as additional patches to this email.

This is why I judged the advantages of renaming to outweigh the 
disadvantages. If despite all this you prefer to not rename src/regex.c 
we could do that fairly easily. Not renaming src/regex.h would be a 
bigger hill to climb, one that I expect is not worth it.

> 3. Is it really necessary to pull mbrtowc, locale_charset,
>     nl_langinfo, and their dependencies?

I didn't know, so in my first cut I did the easiest thing and pulled 
them all in. It's pretty easy to omit them; we can always add some back 
if we find they're needed after all. Revised patch attached; it is the 
first patch in the attached series. (The later patches are some of the 
simplifications mentioned above.)

> P.S. Is it true that this version will no longer support a build with
> WIDE_CHAR_SUPPORT undefined, i.e. those which have only the C locale?

I don't see any issues with such a build. What sort of problem do you 
have in mind?

[0001-Use-Gnulib-regex-for-lib-src.txt (text/plain, attachment)]

[0002-Simplify-regex-emacs-code-by-assuming-Emacs.txt (text/plain, attachment)]

[0003-Simplify-regex-emacs-by-assuming-Emacs-syntax.txt (text/plain, attachment)]

[0004-Remove-always-0-struct-re_pattern_buffer-members.txt (text/plain, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.