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

[Daiki Ueno]

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.

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

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.

>> 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,
-- 
Daiki Ueno