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


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

Reply via email to