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
