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.
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.
> -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.
> 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.
> 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.
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.
> 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.
On the other hand, I don't feel it's time to use any beta-version of
Automake.
So I'll change handling the sources to Automake when either MC splits or
Automake releases 1.5 or the hell freezes over, whatever happens first :-)
> > 4- create_vcs ? Who's still missing /dev/vcs* or /dev/MAKEDEV
> > (or not using devfs) ? More, create_vcs isn't installed by make
> > install or discussed in the FAQ .
>
> Seems this can be removed.
I agree. It's a linux-only hack, and Linux has long outgrown this issue.
--
Regards,
Pavel Roskin
