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 <n@xxxxxx> 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 _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
