Re: MC 4.5.55 tagged, 4.5.x branch created

[Pavel Roskin <proski gnu org>]

Hi, Timur!

Sorry for the tone of the yesterdays private message - I was too tired and
didn't want to guess the missing details from your report.

> Can you, please, revert your changes to fsusage.c and mountlist.c,
> where you removed inclusion of <sys/param.h>.

Reverted.  I guess your system is *BSD - I remember fixing AC_GET_FS_INFO
macro to include sys/param.h before sys/mount.h because of problems on
FreeBSD 4.3.

> I do like the idea of global.h as a place, where all common .h files
> are included(actually, I introduced it), but in this case it gives
> more troubles, than advantages...

The idea was to include sys/param.h before glib.h to avoid a warning about
MIN and MAX being redefined.  I didn't try to put all includes into one
file - I only tried to enforce this particular ordering.

> Or, we need to perfore more global cleanup of the headers and order
> the properly..

I think it's needed, but it should be possible to do it an a more
evolutionary way.

> Also, your cleanup of acconfig.h was too radical :) I wasn't able to regenerate
> configure(with v.2.13) without bringing back HAVE_SOCKET, nlist_t and mode_t.

In fact, I believe that the requirements for the build tools should be
changed.  The resent conversion to Automake for all makefiles except vfs
requires at least Automake 1.4a because it uses AM_CFLAGS and AM_CPPFLAGS.

Autoconf 2.13 doesn't have AC_SYS_LARGEFILE, but it's now default in the
snapshot, and will be default in the release.

I'm inclined to change the requirements to the latest released versions -
Autoconf 2.52 and Automake 1.5.  Supporting different build systems is
rather counterproductive, as it reduces the number of the "qualified
eyeballs" examining the software that will actually be released, and
instead fitting the project to their systems.

> Another idea - mountlist, AFAIR, came to MC from fileutils, together
> with fsusage, maybe, it's reasonable to update this files to the
> current state of fileutils?

And what should we do with the changes made in the MC sources, for example
support for QNX (classic, not Neutrino)?

I'm not going to do this two-way merge, but you are welcome to try.

That's, by the way, shows a good reason to avoid code duplication - you
may do a cool thing today, but you are stuck with the old code tomorrow.

> P.S> BTW, why don't we use cyrillic to communticate :)?

I really want MC to become a community project, as opposed to a project
developed by a small group of hackers for themselves.  This means that all
the discussions about the software should be public.  I don't think it
would be appropriate for me as a maintainer to develop the project based
on discussions that not everybody interested can participate in or even
read.

-- 
Regards,
Pavel Roskin