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
> > 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.
Generally speaking, there are two approaches to the problem of dependent
files on the version control. One is to have them and another is not no
have them.
The answer is - whatever is more convenient for the developers. I have no
strong preference - I can live with any approach.
> > 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. There was
no publicly accessible CVS repository. There was nobody to send the fixes
to. I think that the GNOME developers were right not to fork gettext at
that time.
> > > 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
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.
> > 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.
Not sure if I understand you correctly. I'm just saying that no version of
Automake after 1.4 is really stable. 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.
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.
> > 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.
If you want to update Midnight Commander then wait for an answer from
Miguel. I have no problems updating gettext (I'll make it myself if
everyone agrees), but I cannot make such decisions myself and I don't have
access to unlink intl from the "mc" module (maybe I have access
technically, but not the permission).
> > 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.
The above sentences contradict each other. The later sentence sounds
better, although I don't fully agree with it. On the other hand, the
problems with the build system should NOT be used when making the
decisions about the sources.
By the way, we could switch src/ to Automake and still use the symlinks
for the GMC build. This would work with Automake 1.4.
> > 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.
Once more. I don't understand what you mean by that.
--
Regards,
Pavel Roskin
