On Mon, 2013-05-20 at 07:40 +0200, Pavel Raiskup wrote:
> Yes, it was mentioned multiple times in this thread already and it was
> always forgotten. Please consider this approach.
The patches I've posted include environment variables too.
> One thing was not mentioned here - if there was a CONFIG_GUESS/CONFIG_SUB
> environment variables, what would be the consequences of having it solved
> directly in config.{guess,sub} files?
Both versions of the patch I posted for autoconf used these variables.
> I mean, if there was defined CONFIG_GUESS environment variable, the
> config.guess could try to call 'config.guess' file somewhere in $PATH?
Modifying the config.guess/sub files to call other versions of
themselves was rejected by the maintainers a long time ago. My first
patch was for config.guess/sub to search the system for the latest
version and run it. That was rejected. The current approach is to change
the code that runs config.guess/sub so that it finds the latest
available version and runs it, with the possibility to override, mainly
for folks developing new ports.
> pros: we are able to easily patch also old packages (no-need to
> autoreconfigure)
There would still be a long bootstrap period where old tarballs would
not have any way of running a modern config.sub/guess other than copying
them in from the system versions.
This is a fundamental problem of autotools, it comes from the days when
the system was probably a proprietary, old and buggy UNIX but we now
live in the days of fairly good and up-to-date Linux distributions where
we build software that wasn't necessarily autoreconfed with the latest
version of autotools. We need it to move to a hybrid model; use the
system version of everything unless it is old or missing.
--
bye,
pabs
http://bonedaddy.net/pabs3/
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
