[Top][All Lists]
[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