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