Re: Solving the config.h nightmare ?

[Daniel Reed]

On Sun, 23 Apr 2006, Russ Allbery wrote:
> Daniel Reed <address@hidden> writes:
> > Not if the API has been abstracted adequately. Data types that are used
> > internally should never *need* to be used as part of the API, and hence
> > their changing definitions between library build time and dependent
> > software build time should not affect ABI in any way.
> I prefer to use standard C types like uint32_t and bool in my APIs where
> appropriate rather than hobble and uglify my API to avoid using standard
> types that a small handful of systems don't have.  I'd rather include a

Heartily agreed, but that's somewhat of a different issue. Certainly use 
fixed types and ensure they are available identically everywhere, to the 
point that your API will not be subject to the run of ./configure, or any 
other attribute of the build environment.

In fact, using uint32_t explicitly instead of, perhaps, size_t could 
better aid in surviving when "something changes on the system to change 
the Autoconf results and a package recomputes those values with different 
results, but you don't recompile the library." If you are using 
abstraction types you control (the struct ceylon_widget_t * instead of an 
actual pthread_mutex_t *) or types that have specific [and guaranteed] 
makeup, rather than purposes (uint32_t instead of size_t), then nothing 
determined by ./configure (or otherwise dependent on the build or target 
systems at all) will enter your API, or the dependent-to-your-project ABI.

--
Daniel Reed <address@hidden>      http://shell.n.ml.org/n/        
http://naim.n.ml.org/
It is a miracle that curiosity survives formal education. -- Albert
Einstein, Physicist