Re: 1.1.19-installation fails
On Mon, Apr 10, 2000 at 12:26:46AM +0200, [EMAIL PROTECTED] wrote: Distributing the .mo files means you need gnu gettext on your system anyway, so I do not really see the point. You have to have gettext, indeed, but you don't have to have the tools! That's a big difference. gettext itself is a part of glibc2 and if Maybe you are not aware that glibc2 is installed only on a minority of operating systems. you compile GIMP for libc5 it'll be autotically linked into the binaries, so if you don't want to compile GIMP you don't need gettext. That means that we won't be able to use the native gettext implementation, but always build our own libintl. There is just one problem with this approach: gimp does not yte know that this is the case, i.e. it will try to use the native gettex implementation. Just curious: which one? It's very hard to believe, sort of braindamage... Do you read gimp-developers? Sorry if I told you something that ain't right. Would you please tell me WHAT of the information I gave you has been wrong to give me a change to correct my mind (maybe even other sosurces)? Do you read your mail? -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: 1.1.19-installation fails
On 8 Apr, Marc Lehmann wrote: Yes, I got the impression from all what I was told: a) msgmerge is not checked for by gettext itself b) binary .mo files are being distributed with the gimp Since I was no gettext expert, I just ate it. But now we know better: a) is wrong, since msgmerge is a gno-only thing and b) is bad, since mo files definitely are not portable. Not distributing the .mo files with the GIMP would mean that every one who wants to compile it her/himself has to have a working set of gettext tools. Would be no problem for me, BTW... It's a part of the gettext tools. On Linux you either get both or none. As some people already have said, this is wrong. I'm afraid I didn't get your point here; If you have the GNU gettext tools installed you'll have all of them, if not you'll have none. There is no inbetween. Please note that I spoke of Linux not of any OS in the world. Do the GNU gettext utils work for let's say Solaris, too? If yes, why not rely on them, if we do so on Linux, too? I think it would not be the worst thing if we had somebody with working knowledge of i18n. As it seems, we do not not have such a person :( You are so nice to me... :) -- Servus, Daniel
Re: 1.1.19-installation fails
On Sun, Apr 09, 2000 at 12:50:57PM +0200, [EMAIL PROTECTED] wrote: a) is wrong, since msgmerge is a gno-only thing and b) is bad, since mo files definitely are not portable. Not distributing the .mo files with the GIMP would mean that every one who wants to compile it her/himself has to have a working set of gettext tools. Distributing the .mo files means you need gnu gettext on your system anyway, so I do not really see the point. Just checked, our irix has msgfmt and it's mo files are not compatible with the gnu version. (although it seems they have derived their msgfmt from the gnu gettext sources.. buuh) It's a part of the gettext tools. On Linux you either get both or none. As some people already have said, this is wrong. Please note that I spoke of Linux not of any OS in the world. Me, too: linux configurations that only have msgfmt (and lack msgmerge and msgunfmt) _are_ quite common, at least according to the reports we got. I think it would not be the worst thing if we had somebody with working knowledge of i18n. As it seems, we do not not have such a person :( You are so nice to me... :) I mean it. I was told soo many wrong things from you (and others!) about gettext that I wished there was somebody who knows gimp _and_ gettext, which is not the case. No offence intended, it's just that I had to learn that the hard way :( -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: 1.1.19-installation fails
Marc wrote on Son, 09 Apr 2000: On Sun, Apr 09, 2000 at 12:50:57PM +0200, [EMAIL PROTECTED] wrote: It's a part of the gettext tools. On Linux you either get both or none. As some people already have said, this is wrong. Please note that I spoke of Linux not of any OS in the world. Me, too: linux configurations that only have msgfmt (and lack msgmerge and msgunfmt) _are_ quite common, at least according to the reports we got. AFAI understand the reports: Some (all?) distributions distinguish between gettext-normal and gettext-devel. The fist one has no msgmerge but the second, because it's thought of as an development tool. But since configure doesn't test for both parts (normal and developer) it guesses wrong at the presence of the whole gettext. Uwe -- mailto:[EMAIL PROTECTED] http://rcswww.urz.tu-dresden.de/~koloska/ ---- right now the web page is in german only but this will change as time goes by ;-)
Re: 1.1.19-installation fails
On Fri, Apr 07, 2000 at 05:22:58PM +0200, [EMAIL PROTECTED] wrote: Unfortunately, many systems have msgfmt but do not have msgmerge. This is the default under Solaris (at least for Solaris 2.5.1, 2.6 and Solaris 7) and under SuSE Linux (unless you install the dev rpm that contains msgmerge). I'll check this; if it's true it's definitely a bug. If the gettext tools are installed so is msgmerge or better: has to :) Yes, I got the impression from all what I was told: a) msgmerge is not checked for by gettext itself b) binary .mo files are being distributed with the gimp Since I was no gettext expert, I just ate it. But now we know better: a) is wrong, since msgmerge is a gno-only thing and b) is bad, since mo files definitely are not portable. It's a part of the gettext tools. On Linux you either get both or none. As some people already have said, this is wrong. The same seems to be true for msgunfmt, which means that the original idea of just "msgunfmt | change | msgfmt" to install plug-ins is not possible. I think it would not be the worst thing if we had somebody with working knowledge of i18n. As it seems, we do not not have such a person :( -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: 1.1.19-installation fails
Marc Lehmann [EMAIL PROTECTED] says: The problem is that gettext itself does the detection (and so the only solutioon would be to rpelace the gettext.m4 macros by our own versions). I only get the results. You mean the gnu version of gettext itself does the detection of msgmerge. The problem is that the gnu version of gettext (and msgfmt) is not the only such version. In particular, there is a Solaris gettext and msgfmt but no msgmerge. Bill Sebok Computer Software Manager, Univ. of Maryland, Astronomy Internet: [EMAIL PROTECTED] URL: http://www.astro.umd.edu/~wls/
Re: 1.1.19-installation fails
On Thu, 6 Apr 2000, "William L. Sebok" [EMAIL PROTECTED] wrote: Marc Lehmann [EMAIL PROTECTED] says: The problem is that gettext itself does the detection (and so the only solutioon would be to rpelace the gettext.m4 macros by our own versions). I only get the results. You mean the gnu version of gettext itself does the detection of msgmerge. The problem is that the gnu version of gettext (and msgfmt) is not the only such version. In particular, there is a Solaris gettext and msgfmt but no msgmerge. Hmmm... What he meant is slightly different, but close... When running the "configure" script, it runs some tests to detect what is on your system. Some of these tests are derived from the contents of the file aclocal.m4 that you can find in the top-level directory of the Gimp sources. The file aclocal.m4 is assembled (when the package is rebuilt) from a collection of *.m4 files provided by various packages. One of them is gettext.m4, which contains the tests for checking if gettext is present on your system. The problem is that the tests are verifying if your system has a working version of "msgfmt", "xgettext" and some other tools, but it does not check for the presence of "msgmerge". So it is wrong to assume that "msgmerge" is present if the tests for gettext are successful. Some Linux distributions as well as all versions of Solaris come with "msgfmt" but not with "msgmerge". I think that the only solution is to add a new test with AC_PATH_PROG or something similar in configure.in. -Raphael
Re: 1.1.19-installation fails
On Thu, Apr 06, 2000 at 11:05:10AM -0400, "William L. Sebok" [EMAIL PROTECTED] wrote: Marc Lehmann [EMAIL PROTECTED] says: The problem is that gettext itself does the detection (and so the only solutioon would be to rpelace the gettext.m4 macros by our own versions). I only get the results. You mean the gnu version of gettext itself does the detection of msgmerge. The problem is that the gnu version of gettext (and msgfmt) is not the only such version. In particular, there is a Solaris gettext and msgfmt but no msgmerge. I know (that's why I also do not understand why the .mo files, which are os/architecture dependent, should be distributed with the gimp). The problem is: gimp uses gnu gettext for detection of msgfmt/msgmerge etc.. (regardless of which version is installed on the target system). It is difficult to change this except by re-writing that part, and it does not try to detect availability of a compatible msgmerge. Obviously, I am not keen on re-implementing the whole gettext package just for perl (I had to re-implement most of it already, since it cannot be extended to other languages). :( So I am for a working-but-maybe-not-compliant-to-the-undocumented-gettext solution, but it is difficult to achieve that :( The current (soon-to-be-checked-in) solution to this problem will be to disable any automatic po updates (which requires msgmerge). If translators want an updated pot or po file, they have to "make -C po update-po" themselves (or run po/update.sh) manually. (Which was how it was done a long time ago) -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: 1.1.19-installation fails
On Sun, 2 Apr 2000, Marc Lehmann [EMAIL PROTECTED] wrote: [...] Unless somebody comes up with a better solution, I'll try the following (Without any understanding of what I do): if @MSGFMT@ is != "" and != "no" then just assume MSGFMT is valid, and that msgmerge is somewhere in the path. Otherwise, just suppose @MSGFMT@ a msgmerge are not available. Ahhh... Now I think that I understand why gimp-1.1.19 cannot be built unless you disable Perl (see bug #8148). The problem is that if you find "msgfmt", you also assume that "msgmerge" can be found somewhere in the path. Unfortunately, many systems have msgfmt but do not have msgmerge. This is the default under Solaris (at least for Solaris 2.5.1, 2.6 and Solaris 7) and under SuSE Linux (unless you install the dev rpm that contains msgmerge). I think that msgfmt is more or less standard, but msgmerge is not. You only get the latter with GNU gettext, not with the other versions of gettext. Please add separate tests for msgfmt and for msgmerge. This would probably solve bug #8148. -Raphael
Re: 1.1.19-installation fails
On Sun, Apr 02, 2000 at 03:44:52PM +0200, Hago Ziegler [EMAIL PROTECTED] wrote: gimp-perl.pot; fi msgmerge -w 83 cs.po gimp-perl.pot cs.po~ .. done. iif cmp -s cs.po~ cs.po; then : ; else mv cs.po~ cs.po; fi no -o cs.gmo cs.po make[4]: no: Command not found Hmm, that "no" can only come from MSGFMT. Now the interesting thing is: when I configure gimp and msgfmt is not in the path, configure sets MSGFMT to "". It seems it sets MSGFMT to "no" on your machine. Unless somebody comes up with a better solution, I'll try the following (Without any understanding of what I do): if @MSGFMT@ is != "" and != "no" then just assume MSGFMT is valid, and that msgmerge is somewhere in the path. Otherwise, just suppose @MSGFMT@ a msgmerge are not available. I cnanot believe that this kludge is the real solution, but I have long ago given up on looking for sense in automake/gettext :( -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
