On Wed, 25 Apr 2001, Pavel Roskin wrote:
> Hello, Tomasz and Frédéric!
>
> > > Hi. I have some questions:
> > >
> > > 1- Shouldn't intl/ and ABOUT-NLS be added to .cvsignore or CVS
> > > updated to use GNU gettext 0.10.37 ?
> >
> > Yes.
>
> These are two different questions, so there should be two answers.
>
> Shouldn't intl/ and ABOUT-NLS be added to .cvsignore? Yes if we test it
> and it works well. Actually, in this case intl/ should be unlinked from
> the "mc" module in the GNOME CVS. We may want to add gettext 0.10.37 to
> CVS as the real (not linked) intl/ so that the users of MC CVS don't have
> to have is installed (no a problem for me, but I don't want to create
> inconvenience for anybody).
>
> Shouldn't CVS be updated to use GNU gettext 0.10.37? No unless GNOME
> developers decide to do it. It's not our repository. intl/ is shared.
Both IMHO will be better add to .cvsignore. Why ? because both are
autogenerated.
> A very nice feature in gettext >= 0.10.36 is the codepage support. I
> haven't tested it, but this is an example of what it's supposed to do.
>
> Say, somebody uses LANG=ru_RU. It defaults to the iso-8859-5 encoding.
> However, MC uses translations in koi8-r. gettext 0.10.35 will output them
> as is. gettext 0.10.36 will translate them from koi8-r to iso-8859-5.
>
> This maybe be a problem for those who have a broken environment. Some
> people use koi8-r fonts and LANG=ru_RU without realizing that they should
> be using LANG=ru_RU.KOI8-R instead. Now they will be complaining. I can
> expect similar problems with other languages as well.
>
> In short, updating gettext is not something invisible to the user. Please
> make sure you know what you are doing. It would be better if all GNOME
> programs behaved in the same way.
Hmm I don't see any reasons why nor reequire during autogen.sh gettextize
in version not lower than choosen.
> > -AM_GNOME_GETTEXT
> > +AM_GNU_GETTEXT
>
> I put AM_GNOME_GETTEXT to make MC more coherent with the rest of GNOME.
> It can be undone if we don't want that.
>
> AM_GNOME_GETTEXT disables some features of AM_GNU_GETTEXT. Make sure to
> ask the authors of AM_GNOME_GETTEXT (hint: cvs annotate) about the reasons
> behind this change.
IMHO prepare in GNOME resources macros/gnome-gettext.m4 is wrong way solve
this kind things. Proper way is start prepare some changes directly for
gettext and/or if fixed version gettext will not be releasead time keep
neccessary changes as patch file for gettextize. Now all projects which
uses AM_GNOME_GETTEXT are simple blokaded for uses gettext >= 0.10.36 :>
Many GNOME using projects but not stored on cvs.gnome.org do not uses
AM_GNOME_GETTEXT and seems maintainers this projects have more oil in head
than GNOME devel team :>
> > DEPLIBS = $(top_builddir)/vfs/@LIBVFS@ $(top_builddir)/slang/@LIBSLANG@ \
> > - $(top_builddir)/edit/@LIBEDIT_A@ @INTLDEPS@
> > + $(top_builddir)/edit/@LIBEDIT_A@
>
> This must be wrong. It MC is compiled with included gettext and libintl.a
> changes, mc should be rebuilt.
>
> > DEPLIBS = $(top_builddir)/vfs/@LIBVFS@ \
> > - $(top_builddir)/gtkedit/@libgtkedit@ @INTLDEPS@
> > + $(top_builddir)/gtkedit/@libgtkedit@
>
> Same here.
Yes I know but as I say IMHO it will be better fix gettext resources. In
fact better will be use also:
if test '@USE_INCLUDED_LIBINTL@' = yes; then
DEPLIBS = $(DEPLIBS) $(top_dir)/intl.a
endif
or something other as woraround for this.
> > BTW. Above presents wider problem. Many Gnome projects uses
> > AM_GNOME_GETTEXT and own copy macros/gnome-gettxt.m4 aclocal macros for
> > gettext. Few month ago on gnome-devel I send message about remove
> > completly macros/gnome-gettxt.m4 from all projects and use system
> > installed gettext.m4 and AM_GNU_GETTEXT aclocal macros. Now on switch to
> > new gettext and new automake (>= 1.4b) this above is real problem not
> > only in mc :>
>
> Automake 1.4b is a beta version. Most distribuition still ship
> Automake-1.4 with some minimal bugfixes.
>
> As far as I know, we shouldn't expect a stable Automake release in the
> next few months.
I know one distribution which uses automake 1.4d and I don't see reasons
why some projects isn't be prepared for uses next stable automake
becausesa all automake > 1.4 changes do not disturbs using automake 1.4.
> On the other hand, Autoconf-2.50 with be released really soon, hopefully
> in a few days.
>
> > Miguel can I aply above patch to cvs tree ?
>
> That patch is wrong.
>
> Please make sure you understand whether you are patching GNOME or MC only.
> Ask in the appropriate mailing lists accordingly.
I understand this very well. I know about some wrong behaviors this king
changes and also I know this is much less wrong than using separated
AM_GNOME_GETTEXT aclocal macro.
> > BTW2. Abyone is working on automake suit for mc ?
>
> I know that Automake-1.4 cannot handle building more that one object from
> the same source, which we are using for the files from src/ that are
> compiled to mc and gmc.
If anyone is looking for reason why mc will be separate from gmc it is
IMHO main reason. Amout code shared between mc and gmc is IMHO to low for
keep this in one project tree.
> On the other hand, I don't feel it's time to use any beta-version of
> Automake.
Ones more. All automake > 1.4 fixes do not disturbs using automake 1.4.
kloczek
--
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: [EMAIL PROTECTED]*
