delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2001/04/26/18:30:46

Sender: rich AT phekda DOT freeserve DOT co DOT uk
Message-ID: <3AE8902F.79F65B0E@phekda.freeserve.co.uk>
Date: Thu, 26 Apr 2001 22:16:31 +0100
From: Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.17 i586)
X-Accept-Language: de,fr
MIME-Version: 1.0
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
CC: djgpp-workers AT delorie DOT com
Subject: Re: ANNOUNCE: Fileutils 4.0 beta 2
References: <200104241623 DOT MAA11598 AT delorie DOT com> <8011-Thu26Apr2001140530+0300-eliz AT is DOT elta DOT co DOT il>
Reply-To: djgpp-workers AT delorie DOT com

Hello.

Eli Zaretskii wrote:
> Thanks for working on this.  I finally found some time to download and
> look at this port.

Thanks for trying it out.

> Some comments:
> 
>  1. The binary package:
> 
>     - I think install.exe should be a symlink and ginstall.exe the
>       real thing, not the other way around.  `install.exe' is too
>       ubiquitous a name on DOS/Windows to use it safely; also, many
>       ported packages already force the configure script to run
>       ginstall.

I'll swap 'em round for the release.

>     - There's no need to put both unformatted and formatted man pages
>       in the binary distro; just the formatted are enough.  Although
>       unformatted pages don't hurt, they do bloat the zip size.

I'll remove the unformatted man pages for the release.

>     - Files whose names where UPCASED, such as TODO, NEWS, README,
>       etc. should be stored upcased in the zip, for the sake of users
>       who set FNCASE=y and want to see the file names as they would on
>       Unix.  (If you have difficulty to make this happen, I can
>       suggest how to do that.)

OK, I'll fix that for the release. Please suggest how I would do this. I
do not know off the top of my head, but I could probably work it out.

>     - The port of v3.16 had two programs, d.exe and v.exe, which are
>       missing from this port.  Are they no longer installed by the
>       official distribution?

Oops, I'll fix that in the official distribution.

>     - The problem with "ginstall -s" being unable to work with
>       PMODE/DJ-stubbed executables sounds disturbing.  Does ginstall
>       work with CWSDSTUB?  What about programs compressed with UPX?
>       If these don't work either, I think we need to fix `strip' to be
>       able to work with such programs.

I don't know - I'll look into that.

>     - The messages printed by chown and chgrp are different from those
>       printed by v3.16: the previous port pretended that the
>       owner/group _did_ change, while this port's message says the
>       owner/group were retained, but cites the new owner/group.  This
>       is misleading, IMHO.  What is the reason for this change?

Actually, I made them behave like this, after we discussed some things in
a thread entitled "Porting Fileutils 4.0: chgrp, chown, df", starting on
2000-01-10. chown() always succeeds. Before carrying out the modification
operation, chgrp sets $GROUP to the desired group; afterwards it sets it
back. In other words, the user is considered to own everything and belongs
to every group.

The message is confusing. chown() and chgrp() both contain a function
called describe_change(). I could patch that to display the actual user
and group name, rather than the requested user and group.

>  2. The source distribution:
> 
>     - There are no Makefile's and no config.h, which requires
>       everybody to run the configure script, and have the associated
>       tools installed.  Is there any reason why the source
>       distribution couldn't come already configured, so that users
>       could simply say "make"?

There were many LFN problems with Fileutils 4.0. Some filenames required
massaging to fit into 8+3. Some files had multiple extensions, which
required modifications to automake, autoconf files, some scripts.

I distributed the source with a minimal patch applied. This minimal patch
contains the only changes I made for the port (functional plus 8+3
filename fixes). I could have distributed the sources with a "everything"
patch included. However, I thought that building from minimal changes was
the best way. It was easier to reproducibly configure and build with LFN
and SFN starting with a minimal set of changes, when I was testing.

I can go for the "kitchen sink" approach where the tools aren't needed
("everything" patch applied). I have scripts set up to generate diffs, so
that wouldn't be much work.

>     - config.bat prints annoying error messages:
> 
>         aclocal: aclocal: No such file or directory (ENOENT)
>         autoheader: autoheader: No such file or directory (ENOENT)
>         automake: automake: No such file or directory (ENOENT)
>         automake: automake: No such file or directory (ENOENT)
>         autoconf: autoconf: No such file or directory (ENOENT)
> 
>       I don't understand why does config.bat try to invoke those
>       tools, but if it has to, is it possible to redirect these
>       messages to /dev/null?  Alternatively, if these messages _do_
>       indicate real trouble (see below), I think config.bat should
>       refuse to continue.
>
>     - (Possibly related to the above) It failed to build for me on
>       Windows 98.  I saw several error messages from the configure
>       script:
> 
>         checking whether NLS is requested... no
>         d:/usr/djgpp/bin/sed.exe: can't read ./intl/po2tbl.sed.in: No such file or directory (ENOENT)
>         [...]
>         creating po/Makefile.in
>         d:/usr/djgpp/bin/sed.exe: can't read ./po/Makefile.in.in: No such file or directory (ENOENT)
>         [...]
>         creating config.h
>         d:/usr/djgpp/bin/cat.exe: ./config.h.in: No such file or directory (ENOENT)
> 
>       and then the fatal error message from Make:
> 
>         make.exe: *** No rule to make target `m4/jm-winsz1.m4', needed by `aclocal.m4'.  Stop.
> 
>       (Yes, I did see that readme.dos says I should have Autoconf and
>       Automake installed, but I didn't believe my eyes. ;-) Why would
>       a user be requested to install those, when Unix users don't need
>       them?  Are there any problems which cannot be solved in a way
>       that doesn't require these tools?  If so, let's discuss those
>       problems; AFAIK, this is the first package whose port insists on
>       having those tools installed.
> 
> Given these failures, I didn't try to build on plain DOS; let me know
> if you would like me to do that anyway (I don't have Autoconf and
> Automake on my DOS machine, either.)

RTFMBITBTYD (Read The Flippin' Manual But Ignored The Bit You Doubted) 8)

All these problems are because you haven't got autoconf and automake
installed. config.bat runs these tools to regenerate all the build
framework files (Makefiles, etc.). This is needed because the source is
distributed with the minimal patch applied.

It seems I've taken the wrong approach by depending on autoconf and
automake. I'll fix that for the next release.

Thanks, bye, Rich =]

-- 
Richard Dawe
http://www.phekda.freeserve.co.uk/richdawe/

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019