Re: [gnulib-tool-py] Transitive closure is finished

[Bruno Haible]

Hi Dmitriy,

> I've done some fixes, so now we get the right list of the modules.

Glad you found it!

> Tomorrow I'll implement transitive_closure_separately.

Good! It's recomforting to see that every day, you know where you are (in the
big plan) and what will be the next steps. This is very important. If at
some point you get confused or don't know what to tackle next, please ask.

> I have only two small questions:
> 
> 1. At lines 2859--2871 we have a some strange lines. Why do we need
> to call transitive closure again? Why can't we just use
> main_modules=final_modules? Transitive closure takes a lot of time in
> bash, and I don't want to leave it in Python (though it takes about
> 1--2 seconds to perform transitive closure for m4 package, I don't
> want to waste time again).

For this you need to understand what we generate
  1. in --import --with-tests
  2. in --create-testdir --single-configure.
In these cases we generate two directories lib/ and tests/ with source code
and a Makefile.am for each, and a single configure.ac at the top level.

Now what files go in lib/, and what files go in tests/?
Support we have module A, with a file lib/A.c,
and its tests, modules A-tests, with a file tests/test-A.c,
and A-tests depends on B, with a file lib/B.c.

Will the result be

configure.ac
lib/A.c
lib/B.c
tests/test-A.c

? No, because this would put B.o into lib/libgnu.a, which would be unneeded
code in lib. Worse, A might be under LGPL and B under GPL, and if we put
A.o and B.o together into libgnu.a, the result would have to be under GPL.

So what we do is to generate

configure.ac
lib/A.c
tests/B.c
tests/test-A.c

and generate lib/libgnu.a only from A.o (under LGPL in the above example).

So, we need to manage two lists of modules: The modules which have their
code put into lib/ ([A] in this case), called "main modules", and the
modules which have their code in tests/ ([B, A-tests] in this case),
commonly called "tests related modules".

That's what func_modules_transitive_closure_separately is about: Generate
these two lists of modules.

> 2. Did I understood correctly that we just need to get two lists:
> the first list is for modules whose applicability is 'main', and
> the second is for all other modules?

Yes. When you think about how to produce the two sets [A] and
[B, A-tests] in the case above:
  - The first list is the result of an application of
    func_modules_transitive_closure that completely ignores tests
    (i.e. operates as if --without-tests had been given).
  - The second list is the result of an application of
    func_modules_transitive_closure that includes tests, minus
    the contents of the first list.

> The recommendation how to test bash variables is a very good one,
> I think I'll follow it, though before I've followed such way to get
> the value of variable:
> 
> echo "$sourcebase" > ~/sourcebase
> exit
> 
> All what I need is to put lines like these in the code of the old
> gnulib-tool.

Yes, this is one way to trace and understand a shell script.

Another way is to insert a statement
  set -x
near the top (after the first line), then run the script, while redirecting
its (huge) output to a file. This gives you kind of a step-by-step
execution, but you then need to find your way through this huge trace.

Bruno