Sender: rich AT delorie DOT com
Message-ID: <3908A6AD.7D7FBAC0@bigfoot.com>
Date: Thu, 27 Apr 2000 21:44:29 +0100
From: Richard Dawe <richdawe AT bigfoot DOT com>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.14 i586)
X-Accept-Language: de,fr
MIME-Version: 1.0
To: DJGPP workers <djgpp-workers AT delorie DOT com>
Subject: Re: Some questions about porting fileutils 4.0
References: <39081435 DOT E2EDBC04 AT bigfoot DOT com> <200004272025 DOT QAA25550 AT indy DOT delorie DOT com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com

Hello.

Eli Zaretskii wrote:
> 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).

Yep, it has - I'm running Linux right now, but here it is:

iolanthe:/shared/develop/ports/gnu/filutil4.0 =] ls -al *akefile
-rwxrwxr-x   1 root     dosusers      676 Apr 27 10:13 GNUmakefile*
-rwxrwxr-x   1 root     dosusers    11832 Apr 27 10:15 Makefile*

> 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'.

Well, it seems to be using 'GNUmakefile' for me. When I just type 'make'
it uses GNUmakefile. I have to force 'Makefile' to be used using 'make -f
Makefile'. This happens with make 3.77 and make 3.79.

> So I would guess that something caused the configure script to fail to
> produce `Makefile' in the top-level directory.

No, it's definitely there. Trust me. ;)

> 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.

Yep, there's no SHELL line - I guess from this that's it's using
COMMAND.COM instead of bash. I'll notify the maintainer.

> You are overlooking the file src/djstart.c which I added to Fileutils.

Yes, I just found that (doh) in the diffs.

> The reason for these separate files is that I tried very hard to leave
> the mainline code oblivious to DOS-specific problems.

Yes, I've noticed that from reading through the file 'diffs' from
fileutils 3.16. I will try to avoid #ifdef pollution.

> 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 couldn't really blame them for that. fileutils does seem a little more
DJGPP-aware now, at least in uid, gid handling - there are some '#ifdef
__DJGPP__'s scattered around.

> 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.

OK, I think I'll split src/djstart.c into two files - src/djstart.c and
src/djutils.c.

If things go well, I may have an alpha version out this weekend.

Thanks Eli, bye,

-- 
Richard Dawe
richdawe AT bigfoot DOT com ICQ 47595498 http://www.bigfoot.com/~richdawe/