Date: Thu, 26 Apr 2001 14:05:35 +0300 From: "Eli Zaretskii" Sender: halo1 AT zahav DOT net DOT il To: rich AT phekda DOT freeserve DOT co DOT uk Message-Id: <8011-Thu26Apr2001140530+0300-eliz@is.elta.co.il> X-Mailer: Emacs 20.6 (via feedmail 8.3.emacs20_6 I) and Blat ver 1.8.9 CC: djgpp-workers AT delorie DOT com In-reply-to: <200104241623.MAA11598@delorie.com> (message from Richard Dawe on Sat, 21 Apr 2001 23:47:12 +0100) Subject: Re: ANNOUNCE: Fileutils 4.0 beta 2 References: <200104241623 DOT MAA11598 AT delorie DOT com> Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk > Date: Sat, 21 Apr 2001 23:47:12 +0100 > From: Richard Dawe > > I'd like to announce beta 2 of the port of Fileutils 4.0 to DJGPP. Thanks for working on this. I finally found some time to download and look at this port. 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. - 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. - 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.) - 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? - 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. - 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? 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"? - 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.)