CFO: Why ./configure?

From: VBDis (vbdis_at_aol.com)
Date: 09/01/03 

Date: 01 Sep 2003 01:11:46 GMT

I'm not very well off these days, and my systems aren't either. Or can you tell
me why configure tells me "your compiler cannot create executable files"? My
gcc knows how to create executables, I know that my gcc can do so, only
configure disagrees. And when I remove that obsolete test from the configure
script, everything works fine. But it was not easy to find the according lines
in configure, between those many thousand(!) other lines :-(

But this is only one exceptionally ridiculous example, what nonsense is done
and produced by configure. In almost every tested GNU project configure
prevents me from proceding, due to some condition which was not preseen by the
author of the configure script, maybe human or automake or any other tool.

So my question to everybody is:

Why is it impossible to distribute GNU projects with all the files, which are
required to compile and link the program? What's the special task of configure,
which can not be accomplished in any other way?

IMO configure and many other parts of a project are obsolete. A project can and
should be shipped with immediately usable source files, regardless of the
target platform and other conditions, which the author can not anticipate. Even
if this sounds incredible to you, please let me explain may thoughts, so that
you can point me to the places where my assumptions are wrong.

Let's assume an dumb author, which only knows about his own system, so that his
project will build and work only on his specific system. Let's furthermore
assume an guru, which can make that project build and work on a different
system, which is unknown to the author. Obviously that guru can implement his
solution only, when he has access to all the files, which are required to
compile and link the project. Consequently it's inacceptable if any failure in
the preceding step in the build process will result in missing source or header
files. Otherwise the whole project can not be considered to be portable, if
nobody but the original author can add support for other targets. Okay?

Now let's wrap up the whole build process from the end, so that we can find out
what must and can be done in the preceding steps. In the last step the linker
creates a runnable program, with no unresolved external references. Having
reached this step we have to face several conditions:

- everything is fine - done! :-)
- some library is missing - install and retry.
- no such library is available - back up to the preceding step.

The preceding step in this case is the compilation. Even if the library, as
used by the author, is not available on the target system, there may exist a
workaround. When such a workaround exists, then it can be added to the source
code, and the compiler has to be instructed by some condition (#define), which
of multiple solutions to choose on this special target system. But every such
workaround is not really restricted to a single target system, instead it's
applicable to every system on which the replacement library can be installed.
So the condition really has to reflect the state of the target system,
resulting from the installation of some library. Such conditions need no
complicated guessing by a stupid configuration tool, instead it's sufficient to
#define the according symbol when the library is installed. All what a
configure tool or script can do is a check of the existing configuration file,
with appropriate messages when a required feature is not already installed, and
no workaround is known so far.

This procedure also allows for cross-building projects, when every target
system is represented by the target specific libraries (for the linker), and
the according configuration and header files (for the compiler). All these
files can be kept in distinct target specific directories, as already in use
for gcc. Only that the informations in these directories now are not only used
by gcc, instead all target specific tools and scripts also reside there, so
that the whole build process only needs to know which of these directories to
use. Then also an equivalent of the current Makefile.am is sufficient for
building every project, besides for very special cases like building OS kernels
and related modules or bootstrapping compilers.

Now please tell me what's wrong with this simple model.

DoDi

Relevant Pages

  • problems about gcc installation
    ... i need to install gcc, and when i install it, the following problems ... configure: loading cache ./config.cache ... checking for C compiler default output file name... ... checking whether the linker supports shared libraries... ...
    (comp.unix.programmer)
  • Re: gcc/gnat 3.3
    ... Bootstrapping the compiler ... INSTALL_PROGRAM = $$ ... We want to ensure that TARGET libraries ... all-target-libgloss: configure-target-newlib ...
    (comp.lang.ada)
  • Re: [SLE] Problems with kxdocker
    ... I am attempting to install kxdocker in SuSE10.1 under KDE.. ... checking for gcc... ... checking for C compiler default output file name... ... checking how to recognise dependent libraries... ...
    (SuSE)
  • installing X libraries?? -- need your help!
    ... Then I tried to install a kdm theme called "QtCurve- ... checking for gcc... ... checking for C compiler default output file name... ... checking how to recognise dependent libraries... ...
    (Debian-User)
  • [SLE] Problems with kxdocker
    ... I am attempting to install kxdocker in SuSE10.1 under KDE.. ... checking for gcc... ... checking for C compiler default output file name... ... checking how to recognise dependent libraries... ...
    (SuSE)