[9fans] origins of configure
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. It was inspirational for autoconf, but autoconf doesn't use any of its code, as far as I know. Autoconf was designed to solve real portability problems. In the late 80s and early 90s there was a huge variety of Unix systems and it was really hard to know what was available and what wasn't based on simple ifdefs. The variations were bigger than Erik makes out. Today, the scale of the problem is reduced, since we have POSIX and also fewer systems out there. Much of the bloat in the Autotools is from legacy. But there are still very real portability issues, especially among some of the fringe *BSD systems. MirBSD in particular is one of the worst, but that's another rant. If one were to start over today, one could likely arrive at a simpler system, but portability problems remain, and they are real. Arnold erik quanstrom quans...@quanstro.net wrote: confirmed. it's existence is due to early gnu programs fighting with small variations in unix and compilers. byron's rc used a small script to the same effect. but for the most part, this all could be avoided with careful planning and not using esoteric functions. gcc also had its own configuration step. the header rewriting is a vestage of this system. - erik On Jul 9, 2015 05:31, Jeff Sickel j...@corpus-callosum.com wrote: On Jul 9, 2015, at 5:19 AM, Steve Simon st...@quintile.net wrote: FWIW: fgb did a stirling script called config which sets up some environment and runs configure under ape. It doesn't always work but often gets close to generating a config.h as linux intended. Configure predates Linux. That, or my memory of using it to bang my head against the perl wall in the 1980s damaged the register. -jas … at least you’re not using Xenix From 9fans-boun...@9fans.net Thu Jul 9 07:52:09 2015 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on frenzy.freefriends.org X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=TIME_LIMIT_EXCEEDED autolearn=unavailable version=3.3.1 X-Envelope-From: 9fans-boun...@9fans.net Return-Path: 9fans-boun...@9fans.net X-Virus-Scanned: by MailRoute Date: Thu, 09 Jul 2015 06:50:06 -0700 X-Android-Message-ID: 8f71c132-1b4d-4d0c-a741-d0738945f...@email.android.com From: erik quanstrom quans...@quanstro.net To: Fans of the OS Plan 9 from Bell Labs 9fans@9fans.net Content-Type: text/plain; charset=utf-8 Subject: Re: [9fans] Gawk in 9front-ports X-BeenThere: 9fans@9fans.net X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Fans of the OS Plan 9 from Bell Labs 9fans@9fans.net List-Id: Fans of the OS Plan 9 from Bell Labs 9fans.9fans.net List-Unsubscribe: http://mail.9fans.net/options/9fans, mailto:9fans-requ...@9fans.net?subject=unsubscribe List-Archive: http://mail.9fans.net/private/9fans List-Post: mailto:9fans@9fans.net List-Help: mailto:9fans-requ...@9fans.net?subject=help List-Subscribe: http://mail.9fans.net/listinfo/9fans, mailto:9fans-requ...@9fans.net?subject=subscribe Sender: 9fans-boun...@9fans.net Errors-To: 9fans-boun...@9fans.net X-MIME-Autoconverted: from base64 to 8bit by freefriends.org id t69Dq5Ri006148 Status: R confirmed. it's existence is due to early gnu programs fighting with small variations in unix and compilers. byron's rc used a small script to the same effect. but for the most part, this all could be avoided with careful planning and not using esoteric functions. gcc also had its own configuration step. the header rewriting is a vestage of this system. - erik On Jul 9, 2015 05:31, Jeff Sickel j...@corpus-callosum.com wrote: On Jul 9, 2015, at 5:19 AM, Steve Simon st...@quintile.net wrote: FWIW: fgb did a stirling script called config which sets up some environment and runs configure under ape. It doesn't always work but often gets close to generating a config.h as linux intended. Configure predates Linux. That, or my memory of using it to bang my head against the perl wall in the 1980s damaged the register. -jas … at least you’re not using Xenix
Re: [9fans] origins of configure
On Thu, Jul 09, 2015 at 09:24:57AM -0600, arn...@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
Re: [9fans] origins of configure
I don't intend to engage in yet another 9fans flame war. I do not argue with your analysis or proposal. However, it's based on considerable hindsight and experience that wasn't available when autotools started. Additionally, systems in that time period were changing continually. So it was not always true that what any given system provides is known in advance. The autotools (and especially gnulib) are bloated. A better design is possible. But it's unfair to say that at the time they could have done a lot better; I don't think that's true. Hindsight is always 20/20. That's all I'll say on the topic. Arnold tlaro...@polynum.com wrote: On Thu, Jul 09, 2015 at 09:24:57AM -0600, arn...@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
