The question, however, is whether making this change would now spoil it for people that actually have gettext 0.18 installed on their system. In that case we would have just swapped one problem for another.
Well given that the included gettext files are for 0.18 I think adding
GETTEXT_MACRO_VERSION=0.18
to configure.ac should be completely safe for 0.18 users.
It could conceivably create problems for 0.17 users (like me) but that seems not to be the case.
EDIT
Note that GETTEXT_MACRO_VERSION=0.18 does not specify a requirement.
It simply sets a variable which is then substituted into the various makefiles.
Does this mean that the real problem is that we distribute gettext 0.18 with XBoard in the first place, rather than letting it use the corresponding files from the gettext that is installed on the host system (which ./configure assumes we will be using)? Perhaps these gettext files have accidentally leaked into git and the distribution tar ball, and without them everything would be fine, because ./autogen.sh would just generate them locally?
I did notice that when I use "gettextize -f" to cure this problem (something Tim recommended; don't ask me what it is supposed to do) I create tons of changes in all kind of git files, which leads to inability to switch branches because "the working tree is dirty". I then usually cure that again with a "git reset --hard HEAD", which apparently does not subvert the existing Makefile, so that I am OK until the next time ./autogen.sh is run (which sometimes happens automatically, when I switch to a very old branch).
Does this mean that the real problem is that we distribute gettext 0.18 with XBoard in the first place, rather than letting it use the corresponding files from the gettext that is installed on the host system (which ./configure assumes we will be using)? Perhaps these gettext files have accidentally leaked into git and the distribution tar ball, and without them everything would be fine, because ./autogen.sh would just generate them locally?
Perhaps, but I doubt it. It seems the modus operandi for gettext is to bundle it with the tar ball and to tell autoconf which version you have bundled.
In principle autoconf should be able to autodetect the bundled version but that seems to be somewhat broken. Hence the problems.
autoreconf could correctly detect the bundled version but autogen.sh could not.....
The purpose of gettextize is to update the bundled version. If you do that you should
tell autoconf.
EDIT:
It actually makes some sense that autoconf does not detect the bundled version.
autoconf is there to detect features of the installation system, not features of your application.
Well, if the files are expected to be bundled, I don't see any reason why the configure process would have to involve itself with them at all. We also don't generate make errors when a backend.c from 4.2.7 gets distributed with 4.6.1. (I am sure it would give plenty of compile errors, of course.)
As I understood it, configuring serves to determine what exactly you should use from the host system that was not distributed with the package.
Perhaps it is a mistake that gettext is mentioned in configure.ac altogether.
Yes, it does work on my Ubuntu 10.04. But I still feel a bit queesy about it.
Apparently the macros used are what you have installed on your system (as determined by configure). The problem is that the Makefile.in.in seems to be version-specific in a non-backward-compatible way, and that make actually tests for this compatibility.
Now the solution you propose seems to fool configure into thinking your system has 0.18, whatever it has in reality. This seems to work when in reality you have 0.17 (as we do), and of course when you do actually have 0.18. But there is no guarantee that it would also work for people who have 0.16, or that it will continue to work when we all have 0.19.
Apparently the macros used are what you have installed on your system (as determined by configure). The problem is that the Makefile.in.in seems to be version-specific in a non-backward-compatible way, and that make actually tests for this compatibility.
Are you sure? I think the macros are bundled (in the m4 directory).
No, I am not sure of anything. But if they are bundled, why does autoconf insist they are 0.17, and thus incompatible with the Makefile.in.in? And if they are bundled, what is their left to configure that is used from the host system? It should just trust that what we bundle should be used together.
Problem is that I have really no idea what these macros are for. Or the Makefile.in.in, for that matter. One assumes that there is some process that converts the latter to a Makefile.in, perhaps by expanding these macros?
But if they are bundled, why does autoconf insist they are 0.17,
I think that is simply a bug. But as I said "autoreconf" could correctly detect them.
And if they are bundled, what is their left to configure that is used from the host system? It should just trust that what we bundle should be used together.
Problem is that I have really no idea what these macros are for. Or the Makefile.in.in, for that matter. One assumes that there is some process that converts the latter to a Makefile.in, perhaps by expanding these macros?
