Re: [bug-gettext] activate --enable-relocatable by default for some platforms

[Keith Marshall]

On 24/04/14 08:55, Daiki Ueno wrote:
> Keith Marshall writes:
>>> If I understand correctly, the 'relocate' function merely replaces
>>> the original installation prefix with the given installation prefix.
>>
>> Currently, it appears that its only effect is to wrap the LOCALEDIR
>> argument to 'bindtextdomain()' within a 'relocate()' call, in the
>> caller's scope,
> 
> Yes, it is the use-case illustrated in the manual:
> https://gnu.org/software/gnulib/manual/html_node/Supporting-Relocation.html#Supporting-Relocation

Thanks for the link; I guess I should have deduced that it came from
GnuLib, and that I might have found documentation there.

> and indeed it works as documented, since 'bindtextdomain' doesn't do
> relocation by itself.

It would be kind of useful if it did, especially for MS-Windows hosts.
That was the point Erwin tried to get across, when promoting his patch;
my problem with that was that he based it on Kees Zeelenberg's GnuWin32
relocation machinery, where a more elegant solution based on the GnuLib
code already shipped with gettext may have been preferable.

>> and this occurs only for the tools which are included in the gettext
>> package itself; it has no effect in the general case of any other
>> libintl client.
> 
> FWIW, there are a couple of other places using 'relocate' in libintl:
> locating 'locale.alias' and 'charset.alias' files.  If the client
> defines DEPENDS_ON_LIBINTL=1 and calls 'set_program_name' as described
> in the above manual, libintl should look for the files in the given
> installation prefix.

The problem with that is that we would be dependent on upstream GCC,
binutils, and other NLS capable packages, to DTRT regarding the use of
'set_program_name()', defining the appropriate 'DEPENDS_ON_...' macros,
and calling 'relocate()' on the 'LOCALEDIR' argument, as they pass it to
'bindtextdomain()'; otherwise, MinGW.org would be faced with the
prohibitive task of maintaining local forks of all such packages.  It
would be infinitely preferable for us, if 'bindtextdomain()' itself
could handle those requirements, on entry.

>> It might be useful if the [path] probe is suppressed, in the absence
>> of any language selection environment variable, and to have an analogue
>> for the NLSPATH environment variable, (as it applies to 'catopen()'),
>> for 'bindtextdomain()'; (yes, I do realize that a fully qualified path
>> can be specified for LC_MESSAGES, or other such variable, which may
>> already provide such a capability).
> 
> Yeah, that should be possible.  Maybe we could reuse the GNULOCALEDIR
> envvar used in the OS/2 compat code.

Maybe.  I recall seeing an explanation, from Bruno, why NLSPATH itself
would be unsuitable, and was kind of thinking "aloud".  When Cesar
Strauss first packaged an NLS capable GCC for MinGW.org, he commented in
his release notes: "but it will not work if you install anywhere other
than in C:/MinGW".  I subsequently observed that defining

   LC_MESSAGES=c:/somewhere/other/than/MinGW/share/locale/de

(say) would allow relocation, whereas

   LC_MESSAGES=de

would indeed fail, for any location other than C:/MinGW.

>> It would also be good if we had some mechanism for LOCALEDIR relocation,
>> such as that provided by Erwin Waterlander's patch:
>> https://sourceforge.net/p/mingw/bugs/1808/
>>
>> so that _any_ libintl client would _automatically_ perform the
>> relocation.
> 
> Perhaps we could do some special treatment of the pathname resolution
> for MinGW using 'GetModulePathName()', independently of the
> 'relocatable' stuff, so not to break the current calling convention that
> the 'relocatable' Gnulib module offers.

Maybe, although I'd be inclined to make it more generic; something like:

   #if defined _WIN32 /* && maybe ! defined __CYGWIN__ */
     static char program_path_name[_MAX_PATH];
     if( GetModuleFileName( NULL, program_path_name, _MAX_PATH ) )
     {
       set_program_name( program_path_name );
       LOCALEDIR = relocate( LOCALEDIR );
     }
   #endif

immediately on entry to 'bindtextdomain()', perhaps?  (Apologies for the
incorrect reference to 'GetModulePathName()'; 'GetModuleFileName()' is
the correct function name).

Do note that, on MS-Windows, calling 'set_program_name(argv[0]);' in
'main()' is not guaranteed to retrieve path information, whereas using
'GetModuleFileName()' will do so, regardless of calling context.  I've
not tested the above, but if you'd be willing to consider a patch along
these lines, I'd be willing to play with it.

-- 
Regards,
Keith.