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

[Stefano Lattarini]

Hi Daiki.

On 12/26/2012 07:44 AM, Daiki Ueno wrote:
> Stefano Lattarini <address@hidden> writes:
> 
>> Both in the 'autopoint' and 'gettextize' scripts, in the code of the
>> 'func_find_curr_installdir' function, I see that the following code is
>> used to determine the value of the PATH_SEPARATOR variable:
> [...]
>> I think it might be nice to rewrite this code so that it doesn't touch
>> the file system, the same way it's done by modern Autoconf (a way that
>> is also used by gettext own  file 'gettext-runtime/m4/progtest.m4' BTW):
> 
> 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.

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.

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

Since both autopoint and gettextize are maintainer tools (differently
from ./configure, that is supposed to be able to run by unexperienced
users and on stripped-down systems), the above proposal does not really
introduce any new hard requirement IMO.

But you might probably also want to listen the opinion of someone more
experienced than me before committing to any plan; and honestly, I'd
like to hear such an opinion too ;-)

> I postponed it until the release, since it requires to replace all m4
> quotes and also I wondered if it is the recommended way nowadays; 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.

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

Thanks,
  Stefano