| To work around intractable problems like that, perhaps you could use
| code that looks like this:
|
| ifdef([m4_ifdef], [
| echo autoconf 2.50 or newer
| ], [
| echo autoconf 2.13 or older
| ])
|
| (I was a bit surprised that this worked -- isn't 2.5x supposed to
| rename `ifdef'?)
M4sugar disables them, but autoconf.m4 reinstalls them: leaving them
undefined would have been a good means for me to get fired.
| I'd hate to have to resort to that, but it might be better than
| sticking with 2.13 only.
|
|
| > One problem now is that 2.5x creates configure from old, 2.1x style
| > configure.in without errors, implying that they work, while in fact
| > they don't.
|
| That's a bit too strong, as it worked for me. It depends on the
| configure.in file. The question is whether it's relatively easy to
| write configure.in files that work with both 2.1x and 2.5x.
It can be badly tricky when you use Autoconf internals, but I agree
with Paul: as long you as you stay where you are expected to be, it works.
