On 7/22/07, Ralf Wildenhues <[EMAIL PROTECTED]> 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.
