On Fri, 27 Aug 2010 15:24:18 0200, Enrico Weigelt wrote:
* Peter Johansson <trojkan at gmail.com> schrieb:
> > On 8/26/10 7:19 PM, Enrico Weigelt wrote:
> > >
> > >The actual data will be taken either from a config file or could
> > >be detected on-the-fly (eg. by running a compile test and maybe
> > >caching the result).
> > >
> > >
> > Sounds like autoconf to me.
>
> No, nothing like autoconf at all. The main point is that you
> have a central (per-target) database that is just queried.
> Not dozens of macros that produce unreadable shell code that
> tries to guess something. Pure declaration.
But all that shell code is just a portable way of detecting it on the
fly and caching the result. You'll still need some macros to access the
data. You're just moving the actual detection/caching to a centralized
program that gets called from ./configure (and similar) instead of a
centralized source that gets imported/embedded in ./configure directly.
The only real gain of anything centralized is the cached detection
data--so many different programs all on-the-fly testing compiler
characteristics and headers rather than sharing the "we have gcc, foo.h
exists, sys/bar.h does not exist", etc. Seems like a great feature for
autoconf to have. Since autoconf is so ubiquitous already, would be a
fairly prompt widespread savings rather than gradual (if at all)
adoption of Yet Another Way to do something that is already easy to do
using well-established tools. And indeed, it already does claim to have
sitewide default caching.
dan
--
Daniel Macks
dmacks at netspace.org