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