gnulib-tool-py
[Top][All Lists]
Advanced

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

Re: [gnulib-tool-py] Dependencies with different conditions


From: Bruno Haible
Subject: Re: [gnulib-tool-py] Dependencies with different conditions
Date: Sat, 07 Jul 2012 01:49:28 +0200
User-agent: KMail/4.7.4 (Linux/3.1.10-1.9-desktop; KDE/4.7.4; x86_64; ; )

Hi Dmitriy,

> look into stddef and string modules which
> you can find in the latest commit (you need files from my git, because they 
> are
> a bit modified). You can see that string contains stddef and include_next as
> unconditional dependencies. Module stddef contains include_next with condition
> [$JUST_TO_TEST_DIFFERENT_SITUATIONS = 1]. What happens next: pygnulib sees 
> that
> string has stddef and include_next as dependencies and adds them. When it
> processes through stddef, it finds that include_next is a conditional
> dependency, so pygnulib add it again if it sees that conditions are different.
> 
> The more complicated situation could happen if string had include_next with
> condition [test $SITUATION_1 = 1] and stddef had include_next with condition
> [test $SITUATION_2].
> 
> So, what we must do in such situations? Can such situation ever happen?

Sure, such situations can happen and will happen quite often.

Say, module A depends on D with condition cond_A_D,
and module B depends on D, with condition cond_B_D.

Then the initialization function for A, func_gl_gnulib_m4code_A,
will contain an invocation
  if cond_A_D; then
    func_gl_gnulib_m4code_D
  fi
And 
the initialization function for B, func_gl_gnulib_m4code_B,
will contain an invocation
  if cond_B_D; then
    func_gl_gnulib_m4code_D
  fi

The condition 'true' is worth optimizing in particular, because the
invocation then becomes
  func_gl_gnulib_m4code_D

At this point, in func_modules_transitive_closure, we're only building
up data structures that the function func_emit_autoconf_snippets will
use.

                condition=`func_get_dependencies $module | sed -n -e 
"$sed_extract_condition1" -e "$sed_extract_condition2"`
                if test "$condition" = true; then
                  condition=
                fi

This code extracts the condition from the module description and considers
an empty condition to be equivalent to 'true'.

                if test -n "$condition"; then
                  func_conddep_add_module "$module" "$dep" "$condition"

In the general case (condtion is not empty or 'true'), we just record
to cond_A_D.

                else

In this branch we know that cond_A_D is true.

                  if $conditional; then

If A itself is subject to a condition, no way to optimize. Treat like the
general case.

                    func_conddep_add_module "$module" "$dep" true
                  else

But if A is unconditional (that is, its init function is always executed),
we know that D also is unconditional:

                    func_uncond_add_module "$dep"
                  fi
                fi

Hope this helps a bit.

Bruno




reply via email to

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