Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de> writes: > > platforms, my attitude is 'If it works, great! If it doesn't work, > > who cares?' > > If there's someone to port Autoconf to them, why not? Unless it's very > difficult to go forward with those limited features ... I still think my attitude accomodates that - if someone cares about an old platform enough to post patches to the autoconf list, and those patches aren't too much of a maintenance nightmare, then I'm inclined to include them, because someone has demonstrated that they cared about making things work for their platform (however, I won't be the one posting those patches). And I hope we can all agree that the line at where a patch becomes a maintenance nightmare to work around the limited features of a fringe platform is fuzzy. Or put in other words, I hope that the decision to reject a patch from someone who spent time on working around the quirks of an old platform is based on technical merits such as size and execution impact of the patch, and not the fact taken in isolation that it only helps an older platform. [Either that, or I'm suffering from a severe case of double-speak today :)] I guess my attempt at summarizing the thoughts in this thread about the direction of autoconf: Autoconf continues to be used in a wide variety of projects (not all of which belong to the FSF, or are even [L]GPL), and targetting a wide variety of platforms (not all of which have current vendor support). It is true that support for older platforms will probably break as new features are added, but it is also true that such breakage is unintentional (we aren't going out of our way to penalize people on old systems). When such breakage occurs, anyone is still welcome to contribute patches, and if the patches look reasonable to maintain, they will probably be included, no matter how old the platform is that the patch was designed to help; it's just that the less used a platform is, the less likely that someone will propose a patch. Since Autoconf is an FSF project, we will continue to mention Automake, Gnulib, and other FSF recommended practices; but it remains a recommendation and not a requirement, and the Autoconf testsuite tries to ensure that we do not regress when using Autoconf in isolation. Meanwhile, Autoconf will continue to deprecate macros for two reasons: because it no longer makes sense in modern porting targets (AC_TYPE_LONG_DOUBLE probably falls in this category, even though it has not been marked obsolete yet, since C89 is a reasonable assumption these days); or because it has an inconsistent interface, with pointers to the better interface to use as part of the upgrade (AC_C_LONG_DOUBLE falls into this category; with AC_TYPE_LONG_DOUBLE_WIDER listed in the manual as the replacement that preserves semantics but has a more consistent name). And even when a macro is deprecated, we will still try to keep it working; we are trying to do better about maintaining upgrade compatibility than what has been done historically in the past (or in other words, hopefully some lessons were learned from the 2.13 to 2.50 transition). > > Shells without function support predate even the above mentioned systems > by quite a bit. > I think you meant 'with function support'; and hopefully the problem is like you suspect that at least one shell with function support exists by default on old platforms, even if finding that shell is a bit difficult. -- Eric Blake _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
