Not being a regular library causes no end of constant build problems.
Like this crap because we did “gettextize” without doing “autoconf” (or vice versa):
make[2]: Entering directory `/builddir/build/BUILD/libguestfs-1.14.7/po' *** error: gettext infrastructure mismatch: using a Makefile.in.in from gettext version 0.17 but the autoconf macros are from gettext version 0.18
I just don’t get why gettext can’t be a regular, ordinary, plain library so we don’t have to constantly suffer from this sort of thing. There is surely no other library that needs to rewrite your entire build system.
Richard WM Jones 
Another solution would be to avoid running all autoconf goop during
a build; just commit the configure/makefiles already.
Don’t get me started on autotools!*
The problem here is I need to run gettextize when building from git, but not when building from the tarball. So I can’t have a unified set of patches that build both. So my strategy of maintaining patches in git fails to be compatible with gettext. And it’s not my strategy which is at fault.
I could commit configure output, but that would lead to big, gross git commits.
* To pre-empt any replies, cmake is just as bad, it’s just differently bad.
Put this in configure.ac:
AM_GNU_GETTEXT(external)
to use gettext as a plain library, without the bundled nonsense. Any sane project should do this, bundling libintl is just broken.
> To pre-empt any replies, cmake is just as bad, it’s just differently bad.
Well, this particular issue doesn’t exist at all in CMake, it doesn’t use gettextize at all.
This is a good idea.
Not sure what you mean by “unified set of patches”, but in GNOME we use a script conventionallly called “autogen.sh” which does the required things when building from git. I’ve worked on formalizing this a bit here:
http://people.gnome.org/~walters/docs/build-api.txt
“I need to run gettextize when building from git,”
… then fix it so you don’t have to do that.
gettext cannot be an ordinary library because linking to an ordinary library would not extract the strings, or compile the .po files into .mo files. The error refers to po/Makefile.*; you can either write and maintain those make rules yourself, or use the gettext-provided infrastructure.
Sure, but is running xgettext over your code really that hard that we need the whole ‘gettextize’/’po’ business?