From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Thu,  9 Jul 2015 17:45:57 +0200
From: tlaronde@polynum.com
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Message-ID: <20150709154557.GA2875@polynum.com>
References: <8f71c132-1b4d-4d0c-a741-d0738945f22c@email.android.com>
	<201507091524.t69FOvp2025927@freefriends.org>
Mime-Version: 1.0
In-Reply-To: <201507091524.t69FOvp2025927@freefriends.org>
User-Agent: Mutt/1.4.2.3i
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: Re: [9fans] origins of configure
Topicbox-Message-UUID: 5fc57d58-ead9-11e9-9d60-3106f5b1d025

On Thu, Jul 09, 2015 at 09:24:57AM -0600, arnold@skeeve.com wrote:
> So, the history is more than this.
>
> Larry Wall's Configure (capital C) for rn and Perl was the first step
> at a shell script to examine system features and generate a config.h.

Using a shell script to generate commands to compile on diverging Unices
was, by the date, already used in G.R.A.S.S. from C.E.R.L. and this
predates Perl and so on. I guess it is not the only example.

>[...]
> Autoconf was designed to solve real portability problems.

There are two problems with the autotools stuff:

1) Features are fixed for OSes, but the configuring is done other and
other again for every program. What a system offers shall be known; and
what the developers require shall be known too. Autotools was designed
in a world where neither the OS nor the developers exactly know what
they use;

2) Cross-compilation was not in mind, with some features tested by
compiling and running programs. The result is that the majority of
software built with autotools needs to be compiled natively (even
installed on an equal system since the layout is searched on the
building node);

3) To try to understand what's going on with several steps and huge
configs is out of reach.

Rule: when it takes less time to build a solution from scratch than to
try to understand how to _use_ an existing solution (not to mention
understand), this solution has to be safely stored in /dev/null.

Note: I have put my money where my mouth is : I have built such a
solution: the one publicly used with kerTeX---but it is a side
effect, it was not meant to be released.  And it solves the 1) and
2) and solves too the space problem: when an object is not any
longer necessary, it can be automatically removed, limiting the
space needed to compile to the bare minimum.

--
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                     http://www.kergis.com/
                     http://www.arts-po.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C