autoconf
[Top][All Lists]
Advanced

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

infrastructure for suggested/required packages, and better error reporti


From: Ralf Wildenhues
Subject: infrastructure for suggested/required packages, and better error reporting
Date: Sat, 31 Jul 2010 17:23:15 +0200
User-agent: Mutt/1.5.20 (2010-04-22)

Hello,

several good suggestions for improving Autoconf were made at GHM.
Two of them are a bit related, so I'm sending them in one message.


1) Autoconf should have macros for delayed error reporting.
Example: wget foo-1.tar.gz, run configure, find out it needs bar.
Install bar, only to find out foo also needs baz, etc.

So, we should have something that allows an error message but also
continues the configure script in search for other possible errors,
and summarizes the suggestions and errors at the end.

GNU lilypond (and presumably other packages, too) open-codes such
an approach, see here (search for instances of 'OPTIONAL'):
<http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=blob;f=stepmake/aclocal.m4;hb=HEAD>


2) Similarly, the mail from Joel on bug-gnulib today made me consider
that it might be nice for some packages to produce a summary of tool
and library versions at the end of configure, so infrastructure for
delayed notice reporting would be useful, too.


3) GSRC is a source distribution for GNU, for which it would be nice to
be able to specify in a structured way which packages require which
other ones.  For generalizability to more than GNU, the namespace issues
are probably going to be nontrivial to solve; hopefully somebody else
can worry about that.  For general usability, it might be neat to
introduce build requirements, build optional requirements, and runtime
requirements or optional requirements.

In the simplest case, we could just have macros that expand to nothing,
so all semantics that would be there would be allowing GSRC to extract
the data with
  autoconf --trace=AC_BUILD_REQUIREMENT:...

Going from there, there is an overlap with (1) that could somehow be
used to advantage; of course, actually checking for some requirement
still usually needs package-specific code.


Comments appreciated.

Cheers,
Ralf

PS: and yes, I remember seeing similar suggestions on the list before,
and being sceptical myself.  I probably *just* didn't see the light ...
so if I'm being dumb now, just tell me  ;-)



reply via email to

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