RFC: new target-config tool

Daniel Macks dmacks at netspace.org
Fri Aug 27 07:02:53 PDT 2010

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. 

Daniel Macks
  dmacks at netspace.org


More information about the pkg-config mailing list