Re: Reliance on <config.h>

[James Youngman]

On 7/22/07, Ralf Wildenhues <address@hidden> wrote:
> Hello James,
>
> * James Youngman wrote on Sat, Jul 21, 2007 at 11:34:42PM CEST:
> >
> > My rationale is that the big-lost-of-things-to-do works fine for
> > first-time adopters, but for those who routinely run it, there is no
> > sense of incremental change; there's no easy way of noticing that an
> > extra recommendation has appeared.
>
> gnulib-tool has a nice line-based output, making it amenable to
> comparison tools.  I fear to be pointing out the obvious if I suggest
> putting in import-gnulib/bootstrap something like this:
>
>   gnulib-tool --update | tee new-gnulib-output
>   test -f old-gnulib-output && {
>     echo "gnulib-tool output has changed:"
>     diff -u old-gnulib-output new-gnulib-output
>   }
>   # stop here for ACK of differences?
>   mv new-gnulib-output old-gnulib-output

This approach turns out not to be so useful, because the output of
gnulib-tool depends on two things:
1. The modules you have selected
2. The existing contents of the directory into which gnulib is being imported

Specifically, removing a module on the gnulib-tool command line has no
effect if that module's files were already imported (I assume this is
the designed behaviour).  Some of the rest of the output of
gnulib-tool is lines like these:

Copying file gnulib/m4/i-ring.m4
Copying file gnulib/m4/iconv.m4
Copying file gnulib/m4/idcache.m4
Copying file gnulib/m4/intdiv0.m4
Copying file gnulib/m4/intl.m4
Copying file gnulib/m4/intldir.m4
Copying file gnulib/m4/intlmacosx.m4
Copying file gnulib/m4/intmax.m4

They can cause output differences.  Such differences are not exactly
spurious since the program intentionally produces progress messages,
but it's difficult to isolate those from the messages about the
#includes that should be used or the Makefile variables that should be
set.

James.