On Wed, 25 Apr 2001, Pavel Roskin wrote:
> Hi, Tomasz!
>
> > > 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.
>
> They are not autogenerated now. There are GNOME-specific hacks in
> intl/Makefile.in
Next bad point.
> > > 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 :>
>
> 0.10.35 was the latest revision for years. It wasn't maintained.
Few weeks ago was released 0.10.36. Few days ago 0.10.37.
Seems you are loos something ;)
> > 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
>
> It's supposed to work this way. If we are building with the included
> gettext, then INTLDEPS is defined to '$(top_builddir)/intl/libintl.a'
>
> The ChangeLog for gettext says that the INTLDEPS variable has been
> removed. This means that we should either use another variable or define
> INTLDEPS in configure.in.
>
> Dropping a dependency is wrong.
Look I know about this but seems You do not know only mc uses INTLDEPS
from macros/gnome-gettext.m4. All other projects which uses
AM_GNOME_GETTEXT uses this macro as replacement for AM_GNU_GETTEXT and can
be fixed for proper using aclocal and other by simple replace
AM_GNOME_GETTEXT by AM_GNU_GETTEXT .. and only this. Now maybe you will
see sillynes using AM_GNOME_GETTEXT if you will understand *this* fact :>
[..]
> > 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.
>
> Not sure if I understand you correctly. I'm just saying that no version of
> Automake after 1.4 is really stable.
Ones more. If you prepare Makefile.am files automake > 1.4 compliat this
also will mean you prepare file automake = 1.4 compliat.
> Beta version have problems and limitations. The CVS version of
> automake has 4 expected failures in the testsuite. Apart from that, it
> doesn't install "depcomp" in MC because no C files are handled by
> Automake yet, but configure checks for "depcomp" and prints a warning.
This is not true. I'm using automake 1.4d for rebuild all possible rpm
packages stored on ftp.pld.org.pl (I'm not cot this but possible packages
count checked and sometimes adjusted/fixed on am 1.4d is about hundret).
automake > 1.4 haven't any limitation or problems. Yes this versions
reports some warnings and arror in situactions where automake 1.4 is
silent but in fact all this warning and errors shows *some inccorect
using* automake abilitis.
> Again, I'm risky and I'll personally will have no problems even with
> requiring the CVS version of Automake. But I don't want to lose the
> developers who cannot keep up with the requirements and don't want to use
> unstable software.
Again. I'm practicaly check this. Prepare makefile suit complinat wit >
1.4 am do not bring any risks for using am 1.4.
> > > 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.
>
> You understand this "very well" but you didn't answer my question.
>
> If you want to update GNOME, ask in the GNOME mailing lists. MC should
> easily survive the change. If anything breaks in MC because of GNOME
> updating gettext I promise to fix it in MC within 48 hours.
Ones more. I found only one projects which uses realy some abilities
implementes gnome-gettext.m4. Name this project is mc. All other projects
uses AM_GNOME_GETTEXT as AM_GNU_GETTEXT replacement without prepare all
Makefiles.am files.
> If you want to update Midnight Commander then wait for an answer from
> Miguel.
I'm still wait.
[..]
> > Ones more. All automake > 1.4 fixes do not disturbs using automake 1.4.
>
> Once more. I don't understand what you mean by that.
Ones more. Last few weeks I spend on practical checking this.
kloczek
--
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: [EMAIL PROTECTED]*
