Re: CFO: Why ./configure?

From: Thomas Richter (thor_at_cleopatra.math.tu-berlin.de)
Date: 09/15/03 

Date: 15 Sep 2003 16:48:47 GMT

Hi,

> That's what I mean with "Scheuklappen", most Unix people only can see
> complicated solutions, as used throughout their whole environment. [Sie sehen
> halt einfach den Wald vor lauter Bäumen nicht mehr. Vielleicht kann's ja jemand
> übersetzen ;-] My simple solution, for the above example, would make references
> to specific header files obsolete, and remove the source of such trouble.

It's not that I cannot see that this would make things simpler, but all
this requires that there is an agreement how things should be setup. What is
often not understood by non-Unix folks is that there is no single Unix. There
are several. While I agree that making systems all look alike configuration wise
would make things all simpler, you miss the reality that exactly this won't happen.

It's like in languages: There will never be *the common language*. People will
talk AIX, hpUX, Solaris, Linux, BSD, MacOs and others, and you won't be able to
find a common ground for them.

>>Ad b)
>>"complicate" or "simplify" is a matter of taste, and what you're used for.

> I see many concrete factors, which can express the simplicity or complexity of
> a solution. Of course the scope of such considerations can vary, so that the
> autoconf people will find the invention and use of a new language "simpler"
> than using existing languages. But when we consider autoconf, or any other
> autotool, as part of the overall build process, then the introduction of a new
> tool, and a new language, certainly complicates things. Micro-optimization,
> regardless of whether applied to code, tools, or other procedures, usually
> turns out as introducing only trouble, as soon as any of the implicitly assumed
> conditions changes. Global optimization instead will allow to remove many parts
> of a program or process, so that no micro-optimization is required for
> non-existing things. That's why I consider the build process as a whole, and
> everything what can be removed from any of its components will simplify things.

It's up to you to provide a solution that is as flexible and portable as autoconf
is. Linux as "the project" is open. If your solution provides the same flexibility
and runs on the same platforms as autoconf/configure scripts run now, it could be
a new solution for the same old problems. The *current* proposed solutions all
fail on the diversity of the *ix world, sorry.

The following borderlines are set:

o) Must run on a variety of different system architectures, must be CPU/processor/
architecture independent.

o) Must be independent on the installation (or as independent as possible). Especially,
must run on a variety of systems of which nobody agrees how they should be installed
"correctly". This has the side-effect that you cannot assume that any kind of database
is installed on the target system since it would be part of a standard installation
that is not to be agreed upon.

o) Must be as simple to use as "configure" for the user.

o) Must be simpler to handle for the program author as "autoconf".

configure.in and autoconf are not "designed to be complicated". It's the way the
reality looks like that requires it to be that complex. Rather, for its job it is
astonishingly simple I would say. I don't know how many different systems autoconf
is currently able to handle, but it's rather amazing IMHO.

So long,
        Thomas

Relevant Pages

  • Re: autom4te NOT FOUND ??
    ... >I get a message from BASH when trying to execute, ... that this implies that your autoconf script is probably calling the ... installation. ... This is usually easier than trying to find out why ...
    (comp.os.msdos.djgpp)
  • phpize and autoconf, custom installation of libssh2
    ... I'm on a shared webhost which allows custom php ... libssh2 but I cannot get the server I'm on to find autoconf... ... However, when I run phpize with ./configure, ... I realize it could also be that my installation of autoconf is ...
    (comp.lang.php)
  • Tomcat installation in solaris
    ... But the JK connector installation is giving problem and is much related ... echo "autoconf" ...
    (SunManagers)