> It's what I've done for years. Does it get rid of the problem? I don't > think so but for legacy code that is no longer being maintained, either > you maintain it, or the problem exists into infinity with a hard stop > when someone does maintain it. I think the battle is trying to overcome > continuing the legacy method of needing to replace > config.guess/config.sub within a package and allow a common (or > configurable) location be used as new development takes place. The http://lists.gnu.org/archive/html/autoconf/2013-05/msg00069.html is probably what you are talking about. I like this idea too, but these two ideas are not overlapping, IMO. >From that thread: > Maybe have a common directory of /usr/[local/]share/autoconf/auxdir and > teach autoconf to look there if it doesn't find Even if we were able to "teach" in future our ./configure scripts (not autoconf — as autoreconf -vfi actually solves this even now by calling automake) to look into some configurable place using special option, the ENV VAR solution _may still co-exist_ (and should have always the highest priority). Pavel _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
