Re: [gnulib-tool-py] func_modules_transitive_closure

[Bruno Haible]

Hi Dmitriy,

> I've finally got Internet here

Good! I was starting to worry...

> so I've done a commit. pygnulib now gets dependencies using recursive
> function, so you may test it if you want.

This is OK: you have avoided the potential exponential running time through
the guard
  if depmodule not in self.depmodules

But stack depth may become a problem. Can you please add a comment:
  If this recursion runs into 'RuntimeError: maximum recursion depth exceeded',
  the fix is to call sys.setrecursionlimit.

References:
http://bytes.com/topic/python/answers/25061-runtimeerror-maximum-recursion-depth-exceeded
http://bytes.com/topic/python/answers/802873-maximum-recursion-depth

> However, I can't complete conditional dependencies, because bash doesn't 
> understand
> if I try to type an expression like this:
> 
> [test $HAVE_ATAN2F = 0]
> 
> it says 'unary operator expected'. I guess that it must be something like
> this
> 
> [test "$HAVE_ATAN2F" = 0]

Nah. The 'test $HAVE_ATAN2F = 0' expression is evaluated in a context
where HAVE_ATAN2F has already been assigned a non-empty value, namely
after gl_FUNC_ATAN2F.

You can't test this simply by copying the shell code into bash. To see
this working, you need to create a testdir, such as

$ ./gnulib-tool --create-testdir --dir=/tmp/testdir \
                --conditional-dependencies --without-tests \
                atan2f

In the resulting /tmp/testdir/configure you will find the code

  if test $HAVE_ATAN2F = 0; then
    func_gl_gnulib_m4code_atan2
  fi

This is how the conditional dependency works: The initialization of the
'atan2' module is only conditionally executed, if
   test $HAVE_ATAN2F = 0
evaluates to true.

> In old gnulib I see that conditional dependencies are processed after
> they were separated, but I can't decipher what
> sed_extract_condition# expressions do.

I tried to explain it in
http://lists.gnu.org/archive/html/gnulib-tool-py/2012-06/msg00045.html

                escaped_dep=`echo "$dep" | sed -e "$sed_escape_dependency"`
                sed_extract_condition1='/^ *'"$escaped_dep"' *$/{
                  s/^.*$/true/p
                }'
                sed_extract_condition2='/^ *'"$escaped_dep"' *\[.*\] *$/{
                  s/^ *'"$escaped_dep"' *\[\(.*\)\] *$/\1/p
                }'

Suppose we are looking for the dependency from module A to module B.
sed_extract_condition1 looks for a line consisting of optional whitespace,
then B, then optional whitespace. If found, we use the condition 'true'
(this is a valid shell command: it always evaluates to true.)
sed_extract_condition2 looks for a line consisting of optional whitespace,
then B, then optional whitespace, then an opening bracket, some unspecified
string, then a closing bracket, and finally optional whitespace. If found,
we use the string between the brackets as conditions.

Please use this exact same algorithm for parsing. The interpretation of
existing module description should stay the same.

> I'd suggest a variant like this:
> get words which start with "$" and then add quotes to them. What do you
> think about it?

Don't do this. It would only hide mistakes that may be present in the
module descriptions, and add complexity at a place where transparency is
important. Your method of evaluating these conditions was incorrect.

Bruno