[Bug-gnulib] Re: gnulib-tool --import

[Gary V. Vaughan]

Bruno Haible wrote:
> > 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.

Seems reasonable.

> 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.

I have a dependency generator:

gnulibtool_magic="## This file generated automatically by gnulib-tool "
strip_blank_lines="sed -e '/^[  ]*$/d'"
dirname="sed -e 's:/[^/]*$::'"
basename="sed -e 's:.*/::g'"

# func_update_file dest
func_update_file ()
{
  dest="$1"

  src="${dest}T"
  (
    cd "${destdir-.}"

    if test -f $dest; then
      if cmp -s $src $dest; then
        # Files are the same: remove SRC
        rm -f $src
      elif cat $dest | grep "^$gnulibtool_magic" >/dev/null 2>&1; then
        # Files differ, and contain correct magic: update
        $dryrun || mv -f $src $dest
        echo "gnulib-tool: updating... $dest"
      else
        # DEST does not contain correct magic: ignore
        echo "gnulib-tool: ignoring... $dest (user edits)"
      fi
    else
      # DEST does not yet exist: create it
      $dryrun || mv $src $dest
      echo "gnulib-tool: creating... $dest"
    fi

    $dryrun && rm -f $src
  )
}

# func_get_module_dependencies module
func_get_module_dependencies ()
{
  module="$1"

  modulelist="$module"
  module_dependencies=`func_get_dependencies $module`
  while test -n "$module_dependencies"; do
    new_dependencies=
    for mod in $module_dependencies; do
      case " $module $new_dependencies " in
        *" $mod "*)
          ;;
        *)
          new_dependencies="$new_dependencies
`func_get_dependencies $mod`"
          ;;
      esac
    done
    modulelist="$modulelist
$module_dependencies"
    module_dependencies="$new_dependencies"
  done

  echo "$modulelist"
}

# func_get_all_dependencies modulelist
func_get_all_dependencies ()
{
  modulelist=$1

  modules=
  for mod in $modulelist; do
    modules="$modules
$mod
`func_get_module_dependencies $mod`"
  done

  echo "$modules" | sort | uniq | eval $strip_blank_lines
}

# func_get_modulelist modulelist
func_import_modules ()
{
  modulelist="$1"

  allmodules="`func_get_all_dependencies \"$modulelist\"`"
  for mod in $allmodules; do
    dest=`echo lib/$mod.am | sed "$desttransform"`
    mkdir -p `echo ${destdir-.}/$dest | eval $dirname`
    ( echo "$gnulibtool_magic$version"
      func_get_automake_snippet $mod
    ) > ${destdir-.}/${dest}T

    func_update_file $dest
  done
}

This creates little <module>.am files which I can include into the library 
Makefile.am, which is a start.  Editing them directly into Makefile.am 
wouldn't be difficult from here.

This has a couple of features I like, which I would like to see make it into 
gnulib-tool proper:

- it spots whether you had to override the gnulib snippet and doesn't
  clobber it.  For example, I install xalloc.h as part of the API to
  libm4.la.
- it allows me to specify a transform to tweak the paths for the
  destination files.  Eg. to copy gnulib/lib -> m4/gnulib/m4 and
  gnulib/m4 -> m4/gnulib/config.  From m4/doc/STYLE:

  + The headers in gnulib/m4 need to be managed carefully: gnulib/m4 headers
    can be included by other files in the same directory using `#include
    "file.h"', and from files in other directories with `#include
    <m4/file.h>'.  The include path to invocations of the compiler from
    various Makefile.am are set to prevent the possibility of picking up
    an m4/file.h when the system file.h (e.g stdbool.h) is present.  This,
    in turn means the replacement headers can live in gnulib/m4 without
    suffering a renaming scheme at configure time.  Don't break with the
    `#include' convention, or the compile will go wrong in hard to debug
    ways on some platforms.

    - it honors dryrun mode, and tells me what it is doing without actually
  editting anything.

>   - 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.

Dropping dependencies is trickier...

>   - The tool should add human-readable ChangeLog entries, if not disabled
>     through --no-changelog. Like gettextize does.

Good idea.

> 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.

Out of curiosity: is (1) needed if you have (2)?  I think you can get all
the features you need without it.

> 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?

I think a macro in configure.ac is the right place to declare the list of
required modules:

   gl_GNULIB_MODULES([foo bar baz])

The list of all implicit modules from the last run can be extracted from the
edits made to configure.ac by grepping for "^dnl << ".  I think this is
enough information to detect modules to drop since the last run, provided
the algorithm tracks which of the extracted module names have not been
reinserted on the current run (after dependency analysis).

Do you have some embryonic code you want me to help with?

Cheers,
        Gary.
--
  ())_.  Gary V. Vaughan    gary@(lilith.warpmail.net|gnu.org)
  ( '/   Research Scientist http://www.oranda.demon.co.uk       ,_())____
  / )=   GNU Hacker         http://www.gnu.org/software/libtool  \'      `&
`(_~)_   Tech' Author       http://sources.redhat.com/autobook   =`---d__/