[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bug-libunistring] [PATCH] unicase: Add missing prefix/suffix-contex
Re: [bug-libunistring] [PATCH] unicase: Add missing prefix/suffix-context modules
Sun, 08 Apr 2018 19:58:54 +0200
KMail/5.1.3 (Linux/4.4.0-119-generic; KDE/5.18.0; x86_64; ; )
> whether the above list is complete.
I did not check whether every function/variable/macro described in the
documentation is actually defined in the header files and in the library.
I just _hope_ it is the case.
It would probably be possible to check that every function/variable/macro
declared in the header files is actually defined in the library, by use
> Usually, I bump the required version when there is any change in the
> dependent modules since the last release, using the scripts:
> However, I don't see such changes since 0.9.8. Could you elaborate why
> this change is appropriate, for future improvements of the release
Between 0.9.8 and 0.9.9 we did not change anything, because the only
relevant change was the multithread-safety fix of 'malloca'. Hmm, I don't
know whether a malloca() from before the change and a freea() from after
the change (or vice versa) (one coming from the libunistring.so, one
from the executable) will work well together...
Between 0.9.9 and 0.9.10 we added a couple of modules to libunistring,
that were already included in gnulib.
Why the change is needed? When a program requests a module such as
'unicase/u8-prefix-context' and the module description has
the autoconfiguration (when it finds a preinstalled libunistring
version 0.9.8 or 0.9.9) will not compile the module locally for the
executable, but reference the installed libunistring - thus leading
to a link error. Whereas with
the autoconfiguration will compile the module locally - thus filling
the "hole" in the installed libunistring.
(cd $GNULIB_SRCDIR && git show --oneline --name-only $COMMIT | tail -n+2) \
| ./containing | LC_ALL=C sort | uniq \
| ./dependent | LC_ALL=C sort | uniq
looks only at gnulib, but ignores the libunistring/autogen.sh.
I don't think it is worth to change this recipe, because here we have a
very special case, that ought to not occur any more in the future.