Re: [bug-gettext] Sync the code for determining PATH_SEPARATOR with the one in Autoconf

[Stefano Lattarini]

On 12/27/2012 03:24 AM, Daiki Ueno wrote:
> Hi Stefano,
> 
> Thanks for the comments.
> 
> Stefano Lattarini <address@hidden> writes:
> 
>>> In "autopoint and GREP_OPTIONS" thread, I proposed to use M4sh to
>>> generate autopoint and gettext with common shell functions (including
>>> PATH_SEPARATOR setting) from Autoconf.
>>>
>> Oh, I had forgotten about that.  IMVHO, that sounds like an overkill,
>> and adding an extra layer of complexity that might be better to avoid.
> 
> Agreed.
> 
>> In this case, the simplest solution might be to simply use the AC_SUBST
>> @PATH_SEPARATOR@ in both autopoint.in and gettextize.in.  Less code
>> duplication, and less code to be executed at runtime.
> 
> Sounds a good idea.  Maybe I'll go for it for the time being.
> 
>> About long-term solutions for more general autopoint and gettextize
>> maintainability, I see two ways forward:
>>
>>   - Assume a POSIX shell is used to run them.  This means we'll have
>>     less to worry about the bugs and misfeatures of fringe and/or
>>     obsolescent shells (e.g., Solaris /bin/sh), and will be able to
>>     use modern POSIX features, thus simplifying some constructs and
>>     relying less on external tools.
>>
>>   - Go all the way and fully rewrite the two scripts in Perl (this
>>     assumes the testsuite coverage is good enough to make the chance
>>     of introducing bugs in such a rewrite very, very low; otherwise
>>     we're are just asking for trouble).
> 
> Unfortunately, there seems no single test for autopoint and gettextize.
> Probably good to start from adding tests to study which shell features
> are really needed and how feasible to rewrite them in Perl.
>
Well, if things get too hairy here (i.e., no clearly documented behaviours,
and/or no tests), maybe it's best to just keep these scripts mostly as they
are, with only minor refactorings and optimizations thrown in when the need
arises, and the chance for regressions are low.

>>> it seems libtool recently changed not to use M4sh.
>>>
>> Are you sure about this last statement?  I think Libtool still used m4sh,
>> and heavily ...  Not a good reason for us to do the same here, since
>> Libtools uses it to generate scripts that are to be run on user's
>> systems, and not only by maintainers.
> 
> I couldn't find any discussion related to this in the libtool lists,
> but found the following commits:
> 
> http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=3cf11cfe
> http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=0a42997c
> http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=bbfb7d05
>
Thanks for the pointers, I wasn't aware of this changes.  Too bad they
were not reported on the libtool list ...

> After these changes, libtool seems to embed its own funclib.sh in the
> scripts using build-aux/inline-source, without autom4te.  I thought it
> might be nice if we could reuse that stuff.
>
Might be a good way forward, in the long run.  That funclib.sh should
probably have to be moved to gnulib first, and tests for it added (and
I think it would be better to partly rewrite it to assume a POSIX
shell).  At any rate, this sounds low priority, so I wouldn't worry
too much about it.

>>> Do you have any suggestion to proceed?
>>>
>> See above :-)  But I'm not 100% sure of how sane those suggestions are ...
> 
> Again, thanks for the suggestions!
> 
> Regards,

Thanks,
  Stefano