Josh Berkus <josh@agliodbs.com> writes:
>> Is there a reasonable way to treat libstemmer as an external library?
> Hmmm ... do we want to do that if we're distributing it in core? That
> would require us to have a --with-tsearch compile switch so that people
> who don't want to find & build libstemmer can build PostgreSQL. I thought
> the whole point of this feature was to have a version of Tsearch which
> "just worked" for users.
True.
I just noticed that the upstream master distribution (their compiler
source and .sbl files) weighs in at half the size of the libstemmer
distribution: 68K vs 129K in tar.gz format --- no doubt due to all the
repetitive boilerplate in the generated files. I'm not sure if the
compiler source has any portability issues, but if not it is interesting
to consider the idea of bundling the master distro instead of
libstemmer. This would fix at least one issue that we otherwise will
have, which is that the #include-paths they chose to generate libstemmer
with seem a bit unfriendly for our purposes. The #include commands are
determined by compiler options, so we could fix them if compiling the
.sbl files on the fly.
This makes no difference in terms of the ease of tracking their changes,
of course, but it just feels better to me to be distributing "real"
source code and not derived files.
regards, tom lane
