[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug-gnulib] Re: gnulib-tool --import
From: |
Gary V. Vaughan |
Subject: |
[Bug-gnulib] Re: gnulib-tool --import |
Date: |
Wed, 17 Sep 2003 15:52:24 +0100 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b) Gecko/20030903 Thunderbird/0.2 |
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__/