www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2000/04/27/16:23:38

Date: Thu, 27 Apr 2000 16:25:53 -0400 (EDT)
Message-Id: <200004272025.QAA25550@indy.delorie.com>
From: Eli Zaretskii <eliz AT delorie DOT com>
To: Richard Dawe <richdawe AT bigfoot DOT com>
CC: djgpp-workers AT delorie DOT com
In-reply-to: <39081435.E2EDBC04@bigfoot.com> (message from Richard Dawe on
Thu, 27 Apr 2000 11:19:33 +0100)
Subject: Re: Some questions about porting fileutils 4.0
References: <39081435 DOT E2EDBC04 AT bigfoot 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

> Date: Thu, 27 Apr 2000 11:19:33 +0100
> From: Richard Dawe <richdawe AT bigfoot DOT com>
> 
> 1. The main top-level Makefile is 'GNUmakefile'.

No, the top-level Makefile is `Makefile'.  If you have run the
configure script, it should have created `Makefile' in the top-level
directory (as well as in subdirectories).  When Make is run by just
typing "make [Enter]", it defaults to `Makefile', and only if
`Makefile' doesn't exist (and if it's GNU Make), does it turn to
`GNUmakefile'.

So I would guess that something caused the configure script to fail to
produce `Makefile' in the top-level directory.  You want to understand
what caused that and solve that problem.

> c:/djgpp/bin/test.exe: too many arguments

Ignore this error for now (it probably happens because `GNUmakefile'
doesn't say "SHELL=/bin/sh", which should be reported to the Fileutils
maintainer), but `GNUmakefile' shouldn't run for you in any case.

> 2. src/chgrp.c seems to require lstat(). I looked at the fileutils 3.16
> port and chgrp.c seems unchanged. Since the readme describes chgrp as
> being a no-op program, I was wondering how you made it so, Eli?

Magic ;-)

You are overlooking the file src/djstart.c which I added to Fileutils.
That short file holds the key to many features that magically work in
Fileutils, although the sources themselves don't know about that.

Another file to pay attention to is src/ls-msdos.c, which is important
for understanding how `ls' supports colors and a few other ls-related
tricks.

The reason for these separate files is that I tried very hard to leave
the mainline code oblivious to DOS-specific problems.  File-related
operations in GNU packages are notoriously Unix-chauvinist, and
Fileutils is, of course, the apotheosis of that chauvinism.  Getting
that right in the mainline sources would clutter them with endless
#ifdef's, which no GNU maintainer in their right mind would accept.

I'm not sure I did the cleanest job possible, so please look out for
ways of doing it better, especially since DJGPP now has a few useful
features I didn't have back then.

> I ran configure with
> '--disable-nls' - is there any point attempting to build with NLS, given
> the recent discussion?

IMHO, it is not imperative to have the NLS support, certainly not at
first.  And you are right, we do have a few problems to sort out
before adding NLS could be deemed routine.

> BTW, Eli, I had to upgrade to texinfo 4.0 to read the info docs supplied
> with make 3.79. Is this expected? Until I did this, I could not access the
> section on $(shell ...) from the menu, even though all the info files were
> present.

Yes, this is expected.  Info files produced by makeinfo 4.0 use the
new Ref: tag for footnotes, and versions of info.exe before 4.0 don't
know about Ref:.

- Raw text -


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