autoconf-patches
[Top][All Lists]
Advanced

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

Re: [PATCH 2/5] New FAQ node: Debugging.


From: Ralf Wildenhues
Subject: Re: [PATCH 2/5] New FAQ node: Debugging.
Date: Thu, 8 Oct 2009 23:06:40 +0200
User-agent: Mutt/1.5.20 (2009-08-09)

Hi Bruno,

* Bruno Haible wrote on Sun, Oct 04, 2009 at 02:21:46PM CEST:
> - I like Jim's recommendation to not "requiring users of your macro to
>   use the cache variables". What we see in many places in gnulib is that
>   a macro has a certain purpose/result, which can be stored in a variable
>   or a set of variables. The *_cv_* cache variable is the same as this
>   result only in simple cases. In more complex cases you often have 5
>   *_cv_* cache variable that together determine 1 or 2 result variables.
> 
>   OTOH, the recommendation to use "@var{run-if-true} and @var{run-if-false}
>   parameters" works only for boolean result variables, and requires the
>   user to be familiar with functional programming style.

> 2009-10-04  Bruno Haible  <address@hidden>
> 
>       * doc/autoconf.texi (Debugging): Recommend to use
>       "bash -x -n configure".

Thanks, I completely forgot about -n.  What does -x help in conjuction
with -n though?

>                                 Recommend the use of result variables as an
>       alternative to run-if-true/run-if-false parameters.

I really think that run-if-true/run-if-false ought to be the method of
choice for boolean results.  From an Autoconf standpoint, all else being
equal, it allows to detect more information at autoconf run time, thus
allows autoconf, as well as macro authors, to make better decisions.
And of course, from a functional programming standpoint, it is the
cleaner alternative as well.

I thus propose this patch.  Any objections?

Thanks,
Ralf

2009-10-08  Bruno Haible  <address@hidden>
            Ralf Wildenhues <address@hidden>

        Recommend `sh -n' debugging, and public result variables for macros.
        * doc/autoconf.texi (Debugging): Recommend to use "bash -x
        configure".  Recommend the use of result variables as an
        alternative to run-if-true/run-if-false parameters.

diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 27bb724..b896ee6 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -24340,6 +24340,13 @@ Debugging
 verbosely (@pxref{Debugging via autom4te}).
 
 @item
+Sometimes @command{autoconf} succeeds but the generated
address@hidden script has invalid shell syntax.  You can detect this
+case by running @samp{bash -n configure} or @samp{sh -n configure}.
+If this command fails, the same tips apply, as if @command{autoconf} had
+failed.
+
address@hidden
 Debugging @command{configure} script execution may be done by sprinkling
 pairs of @code{set -x} and @code{set +x} into the shell script before
 and after the region that contains a bug.  Running the whole script with
@@ -24399,7 +24406,8 @@ Debugging
 @item
 by not requiring users of your macro to use the cache variables.
 Instead, expose the result of the test via @var{run-if-true} and
address@hidden parameters.
address@hidden parameters.  If the result is not a boolean,
+then provide it through documented shell variables.
 @end itemize
 
 




reply via email to

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