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)
