Re: infrastructure for suggested/required packages, and better error reporting

[John Calcote]

 Hi Ralf,

On 7/31/2010 9:23 AM, Ralf Wildenhues wrote:
> 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>
>
I use optional packages quite often. One thing I've discovered is that
it's not always possible to enumerate all required packages in the
manner you outline because in some cases, packages are checked for
conditionally based on whether a previous package has been found by an
earlier check.

However, I'm not trying to be negative. I really like the idea, but I
think you'll have more luck getting accurate results by using the trace
option you mention below. One suggestion is that we provide a way of
indicating in the macro that a package will be treated as optional or
required by the rest of the configure script. If we has such a
mechanism, a smart trace utility could provide two lists - a list of
requirements, and a list of optional packages.

This may be too simplistic for all possible scenarios.

Regards,
John

> 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  ;-)
>
> _______________________________________________
> Autoconf mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/autoconf
>