Dmitry Selyutin
2017-12-27 21:51:35 UTC
Hello,
this is a kind reminder that python branch is still alive, though it's quite difficult to find a time
for coding. :-) Anyway, I think I'll finish the "import" section in about a month: right now I'm
slowly processing gnulib-comp.m4 generation part of the code. I have a question regarding a
function named func_emit_autoconf_snippets.
TL;DR: feel free to skip to ===QUESTIONS=== section if this is a way too long introduction to
the topic. :-) The questions mainly target Bruno as the original author, but I'd be very grateful
for any help.
Could you please explain in details how func_emit_autoconf_snippets works? The most
important for me is to understand how to map it into the API I've recently implemented:
currently pygnulib can create a special object, "module database", which allows to iterate over
modules and dependencies very quickly. Basically it is a hash table where each entry contains
yet another hash table.
Given a dependency DEP, it is really easy to iterate over each demander DEM and condition
COND like this:
for (dem, cond) in db.demanders(dep):
print(dem, cond)
One can also iterate over all dependencies of the demander DEM, acquiring each dependency
DEP and the condition COND:
for (dep, cond) in db.dependencies(dem):
print(dep, cond)
So given a set of modules MODULES, I can hopefully obtain all the required information to
implement func_emit_autoconf_snippets analogue. However, I can't quite understand how the
modules are processed. The questions are followed; they all are relevant only for --
conditional-dependencies switch since otherwise the algorithm is trivial (just treat each
module as unconditional).
===QUESTIONS===
1. At line 4260, what's the place where $modules variable gets assigned? The nearest explicit
assignment I've found is at line 5298; is it correct that this is the one whose result is used at
4260?
2. What's the logic for dependencies processing, starting at line 4298?
3. Do you have an idea how could the algorithm mapped to the described API, given that I
have module database, main modules, tests modules and final modules (and hopefully every
other bit of information)? There's no need to check whether module exists, since all the
mentioned collections (database and modules lists) contain not strings, but a real module
instances.
Thank you for your help!
this is a kind reminder that python branch is still alive, though it's quite difficult to find a time
for coding. :-) Anyway, I think I'll finish the "import" section in about a month: right now I'm
slowly processing gnulib-comp.m4 generation part of the code. I have a question regarding a
function named func_emit_autoconf_snippets.
TL;DR: feel free to skip to ===QUESTIONS=== section if this is a way too long introduction to
the topic. :-) The questions mainly target Bruno as the original author, but I'd be very grateful
for any help.
Could you please explain in details how func_emit_autoconf_snippets works? The most
important for me is to understand how to map it into the API I've recently implemented:
currently pygnulib can create a special object, "module database", which allows to iterate over
modules and dependencies very quickly. Basically it is a hash table where each entry contains
yet another hash table.
Given a dependency DEP, it is really easy to iterate over each demander DEM and condition
COND like this:
for (dem, cond) in db.demanders(dep):
print(dem, cond)
One can also iterate over all dependencies of the demander DEM, acquiring each dependency
DEP and the condition COND:
for (dep, cond) in db.dependencies(dem):
print(dep, cond)
So given a set of modules MODULES, I can hopefully obtain all the required information to
implement func_emit_autoconf_snippets analogue. However, I can't quite understand how the
modules are processed. The questions are followed; they all are relevant only for --
conditional-dependencies switch since otherwise the algorithm is trivial (just treat each
module as unconditional).
===QUESTIONS===
1. At line 4260, what's the place where $modules variable gets assigned? The nearest explicit
assignment I've found is at line 5298; is it correct that this is the one whose result is used at
4260?
2. What's the logic for dependencies processing, starting at line 4298?
3. Do you have an idea how could the algorithm mapped to the described API, given that I
have module database, main modules, tests modules and final modules (and hopefully every
other bit of information)? There's no need to check whether module exists, since all the
mentioned collections (database and modules lists) contain not strings, but a real module
instances.
Thank you for your help!
--
With best regards,
Dmitry Selyutin
With best regards,
Dmitry Selyutin