Re: Solving the config.h nightmare ?

[Daniel Reed]

On Sun, 23 Apr 2006, Bob Friesenhahn wrote:
> On Sat, 22 Apr 2006, Daniel Reed wrote:
> > It's almost always a mistake to install generated headers. Distribute an 
> > .m4 with your software that [re]performs all of the checks that dependent 
> > software will need to make. Install that instead of what is essentially 
> > just the cached output of its run (which is what your config.h is, whatever 
> > you prefer to call it) so dependent software devlopers can just call 
> > OB_PROG_CEYLON in their configure.ac and get their own config.h files (or 
> > CPPFLAGS or whatever mechanism they prefer) sanitized.
> This is an interesting approach, but dependent software will then be using 
> tests which are possibly out of date as soon as the dependent package is 
> distributed.  While possibly solving some problems, the approach creates new 
> ones.

So a scenario like:
1. I release libprovider 2.0 with a libprovider.m4 defining DR_LIB_PROVIDER.
2. You release dependentprog 1.0 with a configure.ac incorporating 
libprovider 2.0's DR_LIB_PROVIDER.
3. I release libprovider 2.1 with a new DR_LIB_PROVIDER.

You are worried that installing dependentprog 1.0 might be using checks 
that won't help it interoperate with libprovider 2.1?

Perhaps provider 2.0 only used 32-bit values for its interactions, and 2.1 
adds calls to use 64-bit values. DR_LIB_PROVIDER from 2.0 might have only 
checked for the availability of uint32_t, typedefining __uint32_t or 
_G_uint32_t or unsigned long or whatever in its place as necessary, but 
now <provider.h> is referencing uint64_t and dependentprog only made sure 
uint32_t was available with typedef trickery before including 
<provider.h>.

Luckily, I versioned the API. Perhaps you only see references to those 
uint64_ts (and the API calls that use them) if an AC_DEFINE is in place, 
which is set in libprovider 2.1's DR_LIB_PROVIDER (right after the code 
where it finds you a usable uint64_t) but not in libprovider 2.0's. When 
you wrote dependentprog 1.0, those API calls didn't exist yet, so you're 
not actually losing anything at all by not seeing their prototypes.

My sweat now, in preparing libprovider, ensures other people won't bleed 
later, when trying to use it. I think it is worth it, even if it does 
sometimes require an awful lot of sweat.

--
Daniel Reed <address@hidden>      http://shell.n.ml.org/n/        
http://naim.n.ml.org/
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all progress
depends on the unreasonable man. -- George Bernard Shaw