autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: converting netkit to autoconf?


From: Tom Tromey
Subject: Re: converting netkit to autoconf?
Date: 15 Aug 2002 23:26:15 -0600
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

>>>>> "Russ" == Russ Allbery <address@hidden> writes:

>> Why am I having this sense of deja vu?
>> http://sc-archive.codesourcery.com/sc_config

Russ> BuildConf is basically Autoconf plus Automake, which is useful
Russ> but not what I want and which isn't going to be any easier to
Russ> write probes in than Autoconf is now.  It also brings in the
Russ> whole build system problem, which is a different issue entirely.

Is it really a different issue?  I've often thought that it would be
better to merge configury with the build -- that is, write a single
new tool that replaces all of make, autoconf, libtool, and automake.

I have a few reasons for wanting to merge the two processes.

First, I don't think they are really separable.  Some changes affect
both the configuration and the build (e.g., add a probe for a function
-- you'll change configure, config.h, and presumably some source
files).  I think we tend to think of these as different things, due to
history, but that isn't the only model.

Second, I think in many cases it would be more maintainable to have
configury in the same files as the build.  The current situation is
less maintainable because some choices are made in configure.in and
then used in Makefile.am, leading to a lot of to-and-fro reading when
trying to figure out what is going on.

Third, with parallel make on an SMP box, configure can start to
dominate the build time -- an absurd situation.  If configuration were
integrated with the build, and probes expressed their dependencies,
then configuration could be parallelized.

Russ> Maybe the problem as I'm thinking of it is just too hard to
Russ> really fully solve.

I'm very curious to hear your ideas on how to express probes more
clearly; the more specific the better.  I've been thinking about this
area a lot lately, but I've never considered that Autoconf's method
for expressing tests might be a hindrance.  Personally I've always
found the quoting off-putting but bearable.  Would it suffice to have
a more reasonable programming language (say,
Python/Perl/Ruby/Scheme/[insert your fave here], instead of m4+sh)
with more reasonable quoting rules?

Tom




reply via email to

[Prev in Thread] Current Thread [Next in Thread]