Jean-Marc Lasgouttes writes:
> Enrico> What about autogen.sh in LyX assuming that it will work with
> Enrico> autoconf 2.59 but will not work with 2.59e ?
The difference between this autotools stuff and gcc is that the autotools
stuff is used only by developers. Newer versions of gcc can/will be used
by package maintainers of standard LyX releases.
> Personally, I think we should only discriminate against version that
> are known to break. But it is just me :)
No, that makes sense to me also. However, writing tests that sh will
understand isn't trivial. It's easy for us humans to confirm that our
software meets the bar:
echo "LyX requires automake >= 1.9"
echo "LyX requires autoconf >= 2.52"
Enabling sh to do so is a difficult problem IMO. I'd suggest that we keep
with the present system.
IIRC, Lars' arguments against autoconf 2.59[a-e] were that they were
actually pre-releases of autoconf 2.60. If 2.60 has now been released
then they should all be supported, no? Why not change the script to:
case $autoversion in
+ *' '2.60)
+ *' '2.59[a-e])
*' '2.5[2-9])
EXTRA_ACINCLUDE_FILES="lyxinclude25x.m4"
;;
*)
echo "This autoconf version is not supported by LyX."
- echo "LyX only supports autoconf 2.5[2-9]."
+ echo "LyX only supports autoconf >= 2.52."
exit 1
;;
esac
The 2.59[a-e] line can be removed when these cutting-edge distributions
upgrade to 2.60.
Incidentally, is there any reason for the "25x" in "lyxinclude25x.m4"
anymore now that we no longer support configure.in?
Angus
