Hi Collin,
The patch is mostly good; I've applied it.
One point needs attention, still: In gnulib-tool.sh the code looks at
configure.ac and, if that does not exist, at configure.in:
# Prefer configure.ac to configure.in.
if test -f "$destdir"/configure.ac; then
configure_ac="$destdir/configure.ac"
else
if test -f "$destdir"/configure.in; then
configure_ac="$destdir/configure.in"
else
func_fatal_error "cannot find $destdir/configure.ac - make sure you run
gnulib-tool from within your package's directory"
fi
fi
Whereas in main.py configure.in is not looked at:
# Analyze configure.ac.
with open(joinpath(destdir, 'configure.ac'), 'r', encoding='utf-8') as
file:
configure_ac_data = file.read()
> In gnulib-tool.sh AC_CONFIG_AUX_DIR, A[CM]_PROG_LIBTOOL,
> AC_CONFIG_MACRO_DIR, and AC_CONFIG_MACRO_DIRS are checked under:
>
> import | add-import | remove-import | update ) ;;
>
> In the Python version currently we check for AC_CONFIG_AUX_DIR and
> A[CM]_PROG_LIBTOOL in GLImport.__init__(). This patch adds the checks
> for AC_CONFIG_MACRO_DIR and AC_CONFIG_MACRO_DIRS in main() under:
>
> elif mode in ['import', 'add-import', 'remove-import', 'update']:
>
> Can the AC_CONFIG_AUX_DIR and A[CM]_PROG_LIBTOOL being checked in
> every new GLImport cause any issues?
The only "issue" that I can see with it is that in the case of multiple
gnulib dirs
# Apply func_import to all gnulib directories.
the Python code will read the configure.{ac,in} file several times,
whereas the shell code reads it only once — which is more efficient.
It would be good to move this block of code (GLImport.py lines 90..118)
to main.py. This means that the GLImport constructor takes more arguments.
But I don't see a use-case of creating a GLImport object other than from
main.py.
You can do this move and the fix of the problem mentioned above in one
patch.
> I've made one style change:
>
> - current_edit = int()
> + current_edit = 0
>
> I've just changed it now since it was confusing to me and there are no
> other occurrences of this convention.
Good.
Bruno