Re: a saner bootstrap script

[Gary V. Vaughan]

Hi Stefano,

On 26 Sep 2011, at 18:06, Stefano Lattarini wrote:
> 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.

Either added by autopoint or gnulib-tool, yes.

>>>> @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

That's better than nothing, but catches 2 or more %s specifiers and not
'exactly two'. This is far from perfect too, but a step closer perhaps?

  case `echo $po_download_command_format |sed 's,[^%]*\(%[^%]\),\1,g'` in
    %s%s) ;;
    *) fatal 'invalid format in $po_download_command_format' ;;
  esac

??

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)