From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <24cef4c322f9d480fa9dd6ff42482598@collyer.net> To: 9fans@cse.psu.edu Subject: Re: [9fans] Re: configure misery From: Geoff Collyer In-Reply-To: <200311160804.hAG84F7Y002284@skeeve.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Date: Sun, 16 Nov 2003 00:37:15 -0800 Topicbox-Message-UUID: 8ab48fd4-eacc-11e9-9e20-41e7f4b1d025 configure is undeniably convenient when it works; it's the times it doesn't work that are a pain. If the configure authors haven't seen your particular variant system, configure is very likely to either generate an incorrect configuration or blow up and refuse to run. The incorrect configuration isn't too bad; you can just edit config.h. But when it refuses to run, you then get to wade into the `object code' shell script, which is dense and complicated, and try to persuade it to do the right thing and continue to run. I find that deleting large sections of configure often accomplish this. If that fails, compiling by hand may be easier than coaxing configure into working. And you get to do this for every program you try to import that uses configure. And some of the things that configure probes for just aren't worth probing for. Every ANSI/POSIX C implementation has to provide a compiler under the name `c89'. So why does configure still probe for compiler names? If you have a very old system and still don't have an ANSI C implementation, you're going to have a very hard time importing software in general and you probably ought to go get one (lcc and gcc are just two that come to mind). configure also tries to verify that the compiler it has found generates .o files. I know this isn't required by the 1989 C standard and I doubt that POSIX requires it, and indeed some ANSI compilers we know don't generate .o files. Similarly, configure probes for the system include-file directory; why does it care? The whole process would work *better* if configure just stopped checking for things like this. After all, how many systems have commands named `c89' that don't generate locally-appropriate object files? And cross-compilation would seem to be out of the question with configure, unless configure runs itself remotely on the target and drags the answers back. I think one can live in the real world and still find configure to be a larger problem than the one it claims to solve.