[Bug-gnulib] gnulib-tool --import

[Bruno Haible]

> > Instead of this patch, I'd encourage you to work on "gnulib-tool
> > --import".
>
> Is there a spec?  Or more specifically: Should import merely copy module
> files and their dependencies?  Or does it edit
> {configure.{ac,in},Makefile.am}s too?

It should edit the configure.{ac,in} and Makefile.am's too, like other wizards
(gettextize etc.) do.

What we have now is that "gnulib-tool --create-testdir" creates a complete
test directory with m4/ and lib/ subdirectories. "gnulib-tool --import"
should do the same in an incremental way. That is, when it's called the
first time on a package, it adds everything to the existing package.
When it's called subsequently, it only updates the package where necessary.

Special requirements are:
  - The tool should care about dependencies. Say, someone does
    "gnulib-tool --import A", and A depends on B, then module B must be
    imported as well.
  - If dependencies change: Assume A now also depends on C, then module
    C must be imported as well. And if A doesn't depend on B any more,
    then B should be dropped if it wasn't requested on the command line
    and if no other requested module (directly or indirectly) depends on it.
  - The tool should add human-readable ChangeLog entries, if not disabled
    through --no-changelog. Like gettextize does.

So the tool must make modifications to the configure.ac and Makefile.am,
and update them when run. I've started using the following markers in
lib/Makefile.am so that the tool can recognize where the lines are that
it is allowed to update.

# >>> gnulib module alloca.
[Here comes the Makefile.am snippet for module 'alloca'.]
# <<< gnulib module alloca.

Similar markers (with dnl instead of #) should be used in configure.ac.

The main point where I'm stuck is: For the dependency analysis during
an updating invocation of "gnulib-tool --import", it's necessary to know
1) the list of modules explicitly requested on the command line on the
   last invocation,
2) the list of modules implicitly requested through dependency analysis
   on the last invocation.
Where are these two lists stored? In packages using CVS, should this
information go into the CVS? Is it therefore appropriate to put it into
configure.ac?

Bruno