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

[Daniel Reed]

On 2004-09-13T14:25-0500, Bob Friesenhahn wrote:
) On Mon, 13 Sep 2004, Daniel Reed wrote:
) > 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.

My point is that an interface can be written that depends on a particular
environment, being a set of requirements. In fact, all interface headers
depend on particular environments to some degree: My contention is that the
scope of the environment need not be a lowest common denominator of all
underlying system environments out there.

Whenever an interface uses the type "void" it is relying on a non-guaranteed
(non-universal) aspect of its environment.

Whenever an interface uses a numerical type other than char, it is relying
on a non-guaranteed (non-universal) aspect of its environment: The size of
the type for things like long and double, the availability of the type for
things like uint32_t.

There are two ways to deal with this. Build systems can perform checks at
build time and encode the results in exported interface files, or build
systems can perform the checks at build time and have documented that any
dependent software must perform similar checks.


) You are saying that it is ok if an application which compiles stops
) compiling if it includes a header file for a library which is
) configured via autoconf?  The dependent application is then
) responsible for supplying the missing stuff necessary to allow the
) included header file to compile?  I don't agree that this is ok.

If example-util's build system does not check for the availability of const,
and example-util uses libexample's header files which do use const, the
build will fail.

On the other hand, if libexample's build system detected a lack of const and
includes a workaround (for example, defining "const" away with a
preprocessor macro), then later example-util is compiled in an environment
that *does* have const, building example-util with libexample's header files
will change the behavior of example-util in unexpected and unnecessary ways.


The former can be mitigated by having libexample's developers distribute a
libexample.m4 file which can be referenced during example-util's build
environment setup, to avoid requiring that example-util's developers track
libexample's individual requirements.

The latter problem can only be mitigated by providing workarounds for
workarounds. This is not a practice I would like to investigate or
encourage.


) Autoconf is not currently providing a guarantee or simulation of any
) environment.  A configure.ac file *can* request that certain POSIX
) typedefs be emulated (via "config.h") if they are not otherwise
) available.

This shows that it is possible to do things the way I have been suggesting.


) Every package is responsible for assuring that its own
) requirements are met.  Packages are not responsible for assuring that
) the requirements of *other* packages are met.

For the purposes of maintainability and extensibility (particularly in the
face of environmental changes that could not have been predicted at original
time of package development), dependent packages *must* be cognizant of and
able to guarantee the required environment for its dependencies.

If a provider hardcodes "const" away, things can break in strange and
mysterious ways.

If a provider uses an ambiguously-sized type in its API, and that type
changes due to an environmental change, ABI breaks unnecessarily (and
potentially begins to exhibit strange and mysterious hard-to-track
failures).

If a provider exports different API calls based on its build-time
environment, and the provider is later rebuilt in a different environment,
ABI breaks unnecessarily. Dependent software may not be able to take
advantage of new features, or it may be unable to locate symbols that
disappeared out from underneath it.


These are all aspects of software design, and can not be reliably solved by
the autotools.

Repeating, because it is important: Attempting to solve design flaws in your
software (or, as is more likely in this audience, design flaws in software
you are depending on) with the autotools is unmaintainable.

It is also largely unsupported.

This may be why there exists a "knee-jerk reaction" to mention of the
distribution of autoheader-generated, non-interface headers as part of your
software's interface.

It may also be why autotools maintainers are not interested in "fixing" the
problems you encounter while distributing autoheader-generated,
non-interface headers as part of your software's interface.

-- 
Daniel Reed <address@hidden>    http://people.redhat.com/djr/   
http://naim.n.ml.org/
A democracy is a sheep and two wolves deciding on what to have for
lunch. Freedom is a well armed sheep contesting the results of the
decision. - Benjamin Franklin