Hi Dmitry, > 1. At line 4260, what's the place where $modules variable gets assigned?
Indeed the comments for function func_emit_autoconf_snippets are misleading: This functions receives two module lists: $modules (implicit), $1 (explicit: first argument). Where does $modules come from? - For the invocation in func_import, line 5640 and 5659 it is set at line 5298. But I'm not sure this was intended this way, maybe another list should be used instead of "$main_modules"? - For the invocation in func_create_testdir, line 6288 and 6290 and 6402 and 6404 and 6417 it does not appear to be set in a consistent and correct way. (It is set differently if $single_configure and ! $single_configure.) This is probably a bug. The set of modules that _ought_ to be used here is the set of modules being used for the current configure file. That's my current understanding. But I'd really need to look at a couple of test cases in order to firmly answer the question. > 2. What's the logic for dependencies processing, starting at line 4298? First the code intersects $deps with $modules. This matters for two cases: - when --avoid is used: we don't want to invoke the initialization code for a module that is not present because the user has required it to be avoided. - when ! $single_configure and we are generating the configure file for the tests directory: we may have a dependency from a module in $tests_modules to a module in $main_modules, but since the $main_modules are in a different directory they should be all treated like --avoid'ed modules here. Then the test if func_cond_module_p "$dep"; then is based on the consideration that the unconditional modules have their initialization code already emitted (unconditionally) by lines 4261..4271. Then comes the conditional invocation of the initialization code echo " if $condition; then" echo " $shellfunc" echo ' fi' with a trivial optimization for the (frequent) case that $condition = "true". > 3. Do you have an idea how could the algorithm mapped to the described API You need db.dependencies($module) here. db.demanders(...) is not used here. db.demanders(...) will be useful, in order to implement a new command-line option --extract-reverse-dependencies. Bruno