On Mon, 10 Apr 2000, [EMAIL PROTECTED] wrote:
> On 10 Apr, Marc Lehmann wrote:
>
> > Maybe you are not aware that glibc2 is installed only on a minority of
> > operating systems.
>
> Where's the point? gettext is also available outside of glibc2.
>
> > That means that we won't be able to use the native gettext
> > implementation, but always build our own libintl.
>
> On these systems: yes. Or you forget about internationalisation
> quickly.
Let my try to bring a bit of sanity in this discussion... ;-)
Here is what I understand from the messages posted here:
- The gettext program and library are available outside of the GNU gettext
package.
- Most of the Gimp internationalisation works fine with the native gettext
(e.g. on Solaris) and does not require GNU gettext.
- The automake/autoconf test for gettext supplied in the GNU gettext.m4
checks that a working version of gettext (program and libraries) exists
on the system, but does not cover any other optional program such as
msgmerge and msgunfmt.
- In the perl directory, some .po files have to be rebuilt using msgmerge.
- In gimp-1.1.19, the .po files mentioned above must be rebuilt every time
because they depend on gimp-perl.pot which depends on a "force" target
(see bug #8148)
And here is what I would suggest from the facts presented above:
- We should not require GNU gettext because the native implementations
are good enough. Only the people actively working on i18n could have a
requirement to use GNU gettext and the associated tools, but the other
developers who only want to compile the Gimp from the source distribution
should be able to do it with the native gettext of their system.
- msgmerge should be optional. If the rules for rebuilding a target must
use msgmerge, then we should make sure that these rules are never
triggered in a normal build (i.e. if someone tries to compile the Gimp
from the source tarball without modifying any files). This means that we
should make sure that all dependencies for this target are already
satisfied when a distribution is made. No dependencies on "force"...
- There should be a new test in configure.in, which checks specifically
for the presence of msgmerge, since gettext.m4 does not contain this
test and was probably never intended to do this. This test must be
allowed to fail so that msgmerge is optional. This could be something
as simple as adding AC_CHECK_PROG(MSGMERGE, msgmerge, msgmerge) in
configure.in and using a test on $(MSGMERGE) in Makefile.am. In other
words, configure.in should check for msgmerge but should not complain if
it does not find it. The generated Makefile would check that msgmerge is
usable, but only in the rule that uses it (and this rule should not be
triggered in most cases.) If you need an example, look at how gtk+ uses
"indent" but does not require it.
I hope that my suggestions can help a bit...
-Raphael
P.S.: I'm currently having some mail problems. They should be solved in
a couple of days, but don't be surprised if it takes me some time
to reply to the messages sent to me.
P.S.2: Still no replies to my questions about pixmap brushes/hoses... :-(
Any comments that would help me to solve bug #8150 are welcome...
