Re: a saner bootstrap script

[Stefano Lattarini]

On Monday 26 September 2011, Gary V wrote:

> >> @cnindex gnulib_precious
> >> @item gnulib_precious
> >> Normally, @command{bootstrap} removes any macro-files that are not
> >> included by @file{aclocal.m4} before it returns, except for files
> >> listed in this variable which are always kept.
> >> 
> > Are you sure it is a good idea to do so by default?  The potential for
> > disruption seems pretty high to me.  Note that this is an OBJECTION TO
> > THE BEHAVIOUR, not the documentation.
> 
> It is nothing irreversible, as only copies of files added by autopoint
> are removed.  cf doc-comment for `func_clean_unused_macros':
> 
> # Autopoint can result in over-zealously adding macros into $macro_dir
> # even though they are not actually used, for example tests to help   
> # build the `intl' directory even though you have specified           
> # `AM_GNU_GETTEXT([external])' in your configure.ac.  This function   
> # looks removes any macro files that can be found in gnulib,  but     
> # are not `m4_include'd by `aclocal.m4'.                              
>
Ah, so we can be sure that only `.m4' files from gnulib gets removed,
right?  In this case, the behaviour should be ok.

> >> @smallexample
> >> po_download_command_format=\
> >> "rsync --delete --exclude '*.s1' -Lrtvz \
> >> 'translationproject.org::tp/latest/%s/' '%s'"
> >> @end smallexample
> >> 
> > Could a runtime check be added to bootstap, to ensure that an
> > user-overridden `$po_download_command_format' is well formed?
> > Or would the ratio burdens/benefits be too high?
> 
> Well formed in what respect?
>
If I'm not mistaken, `$po_download_command_format' is passed to a printf
call in bootstrap (precisely, in subroutine `func_download_po_files'), so
it should contain two, and exactly two, `%s' conversions.

> Certainly that's a peculiarly finicky bit
> of code that you don't want to screw up, so there's definitely scope for
> saving hair-pulling if there's a way to catch obviously broken command
> specifications here.  I don't have any po using projects though, so I
> didn't work as hard on making this part fool proof as I did on plenty of
> the other features of bootstrap.
> 
> Suggestions are always welcome if you have a specific idea on how to
> implement an improvement.
> 
Maybe some code like this should be enough to catch most potential
erroneous definitions?

  case $po_download_command_format in
    *[^%]%s*[^%]%s*) ;;
    *) fatal "invalid format in \$po_download_command_format";;
  esac

> Thanks again for the review!
> 
Thanks to you for taking all my observations and suggestions into
account.

Regards,
  Stefano