Re: CFO: Why ./configure?

From: André Pönitz (poenitz_at_gmx.net)
Date: 09/15/03 

Date: Mon, 15 Sep 2003 09:46:58 +0000 (UTC)

VBDis <vbdis@aol.com> wrote:
> Im Artikel <bjsakl$l6h$7@anderson.hrz.tu-chemnitz.de>,
> =?iso-8859-1?Q?Andr=E9_P=F6nitz?= <poenitz@gmx.net> schreibt:
>
>>And when it comes to required features: Do you know all your libraries
>>by heart? Do you know which features go together and which don't? Can
>>you tell me at once what version of g++ support partial specialization
>>of templates?
>
> You seem to assume that the autotools will know all that?

Most of it. Yes.

> For every platform and system? How that? How for new platforms,
> tools and libraries, and for every specific installation?

They look for features, not necessarily for names and version (even if
this is possible, too). So if you need feature they try to build a
minimal application that tests for that feature. If that app 'works',
the feature is there.

So in general you do not need a large database mapping of library to
features but only a rough idea what might provide the feature.

If you need a C++ compiler, you'd use 'AC_PROG_CXX' and you can rest
assured that it will be found whether it is named g++, c++, gpp, aCC,
CC, cxx, cc++, cl, FCC, KCC, RCC, xlC_r, or xlC - i.e. even on platforms
I and you've never heard of nor will ever use.

> When configure tests the capabilities of the target system, then these
> tests can fail for several reasons. What if multiple instances of
> libraries exist there, with possibly different properties?

One will be chosen according to an order defined by you.

> What about different versions of installed tools, like compilers,
> which one will configure use during the tests?

Same here. You can state preferences if you wish. It's usually not
needed, though.

> Isn't it better to leave the answers to all questions to the target
> system, which can provide the answers in a more appropriate way than
> any script can, which was written without that detailed knowledge
> about a specific target system?

That's exactly what is done. The configure script runs on the target
system. On your build system you just rely on the fact that AC_PROG_CXX
will find a local compiler (or library or whatever) which has the same
set of features as the thing on your target platform.

Andre'

Relevant Pages

  • Re: Programming With Posix Threads book
    ... I guess I can't really see any other way to characterize exposition of my particular biases and preferences regarding features and usage than "philosophy". ... recursive mutexes can be indispensible -- if only because in the real world you often have to deal with poorly designed libraries you can't fix. ... It's not impossible to build correct -- and even efficient -- threaded code using recursive mutexes and asynchronous cancellation. ...
    (comp.programming.threads)
  • Re: The Lib debate
    ... > Features and the Lib Concept. ... one of the main important feature of RosAsm is... ... object code files and libraries, so I won't cover that again...the ... As I phrased it on the LuxAsm list, most IDEs - including RosAsm's, ...
    (alt.lang.asm)
  • Re: [RFC] kernel facilities for cache prefetching
    ... initial disk quiescence). ... it seems common among system libraries to use this feature. ... An obvious benefit -- if certain features of a program are not used, ... Linux already does lazy loading for linked libs. ...
    (Linux-Kernel)
  • Re: Conformance
    ... features that you want to add to it are of at best marginal usefulness ... currently a superior language. ... this also makes sense in the frontend as well, since new language features can be added as library features, absent having to suffer through horrible syntax, and absent having to hack them into the compiler core. ... libraries, some of which were last updated decades ago. ...
    (comp.std.c)
  • Re: best GUI Lib?
    ... Today you write a supporting library, ... > I design them to be supporting. ... Compete to add features elegantly. ... Libraries are modules for sale. ...
    (comp.lang.cpp)