Re: Use of config.h: summary of responses.

[Daniel Reed]

On 2004-09-13T13:11-0500, Bob Friesenhahn wrote:
)    1) Large file interface (off_t,fpos_t,rlim_t, etc., size changes).
 ...
)    4) Big/little endian CPU type.
 ...
) Notice that I mention LF issues as the first item.  Libraries which
) expose types which are influenced by large-file compilation do not
) illustrate good design and forethought.

These points illustrate that it is possible to design a poor API. It is
possible such APIs could be better designed from the get go, or made better
at an API version bump. The autotools can help with this.


)    2) 'const' support
)    3) 'inline' support

const and other modifiers are exactly the types of things that should *not*
be made dependent on the characteristics of the system build environment.
Interface files should use them in accordance to a particular, fixed
environment, and rely on dependent packages to detect or recreate that
environment as needed. The autotools can help with this.


)    5) User supplied configuration options which influence available
)       interfaces.

This is similar to the libjpeg.so example in my previous message. Software
can be written to not require information about extensions to be available
at build time. This is the style of programming for which the autotools are
arguably most geared.


) > gnu89 and C99 provide guarantees about types and non-C89 routines that can
) > be documented and simulated by the autotools.
) Autoconf is not about guarantees.  It is all about survival without
) guarantees.

The autotools can act as an abstraction layer between the actual system
environment and the environment the code is designed to use. In this
capacity, the autotools can and do allow for guarantees about environment.
These guarantees can be provided by testing for compliance in the underlying
system build environment; by discovering ways to gain compliance by linking
in support libraries; and by providing simulations through macro
definitions, type definitions, etc.


) > POSIX and various other environment standards provide guarantees about
) > networking, file system interaction, and other low-level operations that can
) > be simulated by support libraries, as with the Cygwin kernel or Solaris'
) > libnsl.
) Everything would be easier if we all used operating systems designed
) to the exact same standards and which provided the exact same APIs.

This is why the autotools are so important: They provide a highly-uniform
build environment for software, regardless of the underlying system's
facilities.

If a piece of software is designed with POSIX and other environment
standards as a requirement, the autotools can be used to guarantee or
simulate those environments regardless of the characteristics of the actual
system environment. There should not be a reason to allow characteristics
from the system environment to "leak" into the interfaces of the software.

-- 
Daniel Reed <address@hidden>    http://people.redhat.com/djr/   
http://naim.n.ml.org/
1832 Savior214: that sucks that one day your just gonna die and all that
work you did learning stuff just gets a rm -rf