Hi Daiki, > 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 of SWIG. > Usually, I bump the required version when there is any change in the > dependent modules since the last release, using the scripts: > > https://git.savannah.gnu.org/gitweb/?p=libunistring.git;a=blob;f=Admin/README.update;h=76c9925c2cb63b86b6bbdc62037706c95ac399ed;hb=HEAD#l45 > > 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 > process? 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 gl_LIBUNISTRING_MODULE([0.9.8], [unicase/u8-prefix-context]) 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 gl_LIBUNISTRING_MODULE([0.9.10], [unicase/u8-prefix-context]) the autoconfiguration will compile the module locally - thus filling the "hole" in the installed libunistring. Your recipe (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. Bruno