Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems

[Paul Wise]

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/

signature.asc
Description: This is a digitally signed message part