Switch away from home-grown build system

[ojwb]

The current build system doesn't support shared libraries. Various patches from distros add this but all seem to make assumptions (e.g. shared libraries have extension .so). Switching to something like autotools or meson seems a better way to address this than trying to add support which handles all the platforms people might reasonably want to use snowball on.

This would also provide make install (or equivalent) and make it simpler to provide a .pc file for pkg-config/pkgconf support.

We also currently have a split between the snowball repo's build system and distribution tarballs this generates for some (but not all) target languages which each have their own separate Makefile, generated by GNUmakefile. This was implemented before I took over as maintainer, but I assume the thinking was that it was convenient to users to have a distribution of the pre-generated target language code. However these days there's more concern about supply chain attacks, and also people more often build straight from git, so I think these two levels are just extra complexity we don't need. Even if a future version of the snowball compiler did a lot more optimisation, the stemmers are small pieces of code so it's unlikely to ever take significant time.

[nater1983]

This is based on a patch taken from alpinelinux, however, duplicated
libstemmer.o and stemwords targets were removed and the patch was
rebased on top of v2.2.0 tag.

Created shared library contains a lot of relocations, which slow down loading.
It is known issue and probably the main reason why upstream does not support
shared library yet [1].

[1] https://github.com/snowballstem/snowball/issues/34#issuecomment-203200078

Alpinelinux-patch: https://git.alpinelinux.org/aports/tree/community/snowball/libstemmer-library.patch?id=28f9d9e192876c43fd96bc5856cd9d8a50dd49c0
Upstream-issue: https://github.com/snowballstem/snowball/issues/34

diff --git a/GNUmakefile b/GNUmakefile
index 98eb1fa..9b539ec 100644
--- a/GNUmakefile
+++ b/GNUmakefile
@@ -4,6 +4,8 @@
 # which hard-code it.
 SNOWBALL_VERSION = 2.2.0
 
+MAJOR_VERSION := $(shell echo $(SNOWBALL_VERSION) | cut -d. -f1)
+
 ifeq ($(OS),Windows_NT)
 EXEEXT = .exe
 endif
@@ -170,12 +172,17 @@ C_OTHER_OBJECTS = $(C_OTHER_SOURCES:.c=.o)
 JAVA_CLASSES = $(JAVA_SOURCES:.java=.class)
 JAVA_RUNTIME_CLASSES=$(JAVARUNTIME_SOURCES:.java=.class)
 
-CFLAGS=-O2 -W -Wall -Wmissing-prototypes -Wmissing-declarations
-CPPFLAGS=
+CFLAGS+=-fPIC -W -Wall -Wmissing-prototypes -Wmissing-declarations
+CPPFLAGS+=
 
 INCLUDES=-Iinclude
 
-all: snowball$(EXEEXT) libstemmer.a stemwords$(EXEEXT) $(C_OTHER_SOURCES) $(C_OTHER_HEADERS) $(C_OTHER_OBJECTS)
+all: snowball$(EXEEXT) libstemmer.a libstemmer.so stemwords$(EXEEXT) $(C_OTHER_SOURCES) $(C_OTHER_HEADERS) $(C_OTHER_OBJECTS)
+
+libstemmer.so: libstemmer/libstemmer.o $(RUNTIME_OBJECTS) $(C_LIB_OBJECTS)
+	$(CC) $(CFLAGS) -shared $(LDFLAGS) -Wl,-soname,$@.$(MAJOR_VERSION),-version-script,libstemmer/symbol.map -o $@.$(SNOWBALL_VERSION) $^
+	ln -s $@.$(SNOWBALL_VERSION) $@.$(MAJOR_VERSION)
+	ln -s $@.$(SNOWBALL_VERSION) $@
 
 algorithms.mk: libstemmer/mkalgorithms.pl libstemmer/modules.txt
 	libstemmer/mkalgorithms.pl algorithms.mk libstemmer/modules.txt
diff --git a/libstemmer/symbol.map b/libstemmer/symbol.map
new file mode 100644
index 0000000..7a3d423
--- /dev/null
+++ b/libstemmer/symbol.map
@@ -0,0 +1,6 @@
+SB_STEMMER_0 {
+    global:
+        sb_stemmer_*;
+    local:
+        *;
+};

I wouldnt this be more logical libstemmer.so.2 => /usr/lib/libstemmer.so.2 (0x00007efd7da65000) then having libstemmer.so.0d => /usr/lib/libstemmer.so.0d (0x00007c29bc8df000)

[ojwb]

Sorry, but as I've said a number of times before (even in this very issue!) I can't merge a patch which breaks building on platforms which currently work. Shared libraries aren't named .so everywhere.

(This also patches the wrong place for how the current build system is designed to be used - it's the generated Makefile in the "dist" tarball which you're meant to use to build libstemmer - the build in GNUmakefile is just to allow the testsuite to run, and building a shared library for that would be pretty pointless.)

The lack of shared library support has been unresolved for many years, and I've concluded implementing shared library support properly in the current build system is not a sensible use of effort - we're better off moving to a non-home-grown build system which supports shared library building and knows about all the quirks of different platforms. That's the purpose of this ticket.

If someone really cares enough to come up with a portable patch to the existing build system that provides shared library support I would consider applying it (though I'd encourage anyone considering doing so to instead put the effort into helping us move away from the current build system). Attaching effectively the same distro patches here that have been submitted and rejected already is not helping.