[mercury-users] Problem with mmake

[Richard A. O'Keefe]

Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
	The main problem that I can see with your suggested fix is that the code
	is POSIX code, but some of the systems that we're trying to port to --
	in particular Windows with Mingw or MSVC as the C compiler -- are not POSIX
	systems.

Have you actually *tried* the code under MSVC++, or is this mere
hypothesis?  My rather ancient Microsoft Visual C++ Run-Time Library
Reference lists

    <sys\types.h>		<sys/types.h> also works
    <sys\stat.h>		<sys/stat.h> also works
    <fcntl.h>
    _open()			open() is supposedly also available; basically
				Microsoft misunderstood the C standard's words		
				about "_"
    _O_RDONLY			ditto
    _fstat()			ditto
    _S_IFREG			ditto

which is the core of it.  So we'd need

    #ifdef MSVC
    #define open       _open
    #define O_RDONLY   _O_RDONLY
    #define fstat      fstat
    #define S_ISREG(m) ((m)&_S_IFREG)
    #endif

That's 1993.  It would NOT surprise me if MSVC already supported
opendir(), readdir(), and closedir().

Alternatively, it should be a trivial matter for someone familiar with
MSVC to write something like

	unsigned (*f)(char const *, unsigned, struct _find_t *);
	struct _find_t info;

	for (f = _dos_findfirst
           ; f("*.*", _A_NORMAL|_A_RDONLY, &info)
           ; f = _dos_findnext
	) {
	    namlen = strlen(info.name);
	    if (namlen > suflen
	     && 0 == strcmp(info.name + (namlen - suflen), suffix)
	    ) {
	        puts(info.name);
	    }
	}

except using whatever the modern Windows system calls are that handle
long file names.  (FindFirstFirst/FindNextFile/FindClose, isn't it?)  I
don't have a Windows box or an SDK to try this out on, but if it only
took me 15 minutes to find the right manual in a crowded office and
rough out Windows-appropriate code, how long should it take someone who
_has_ a Windows box?

	On those systems we can use bash and cat from Mingw or Cygwin,
	and probably test -d too, but we can't use Posix stuff like readdir(),
	at least not unless we require people to install Cygwin, and make sure
	that the installation process compiles that file with the Cygwin gcc
	rather than the Mingw gcc.

Have you actually _verified_ that MSVC doesn't support opendir()?

	I still think it is an OS bug, and since it is easy to work around
	at the user level (either by not naming directories *.d or by using
	--use-subdirs), I don't think it is worth adding code to the Mercury
	implementation to work around this OS bug unless the additional code
	added is very simple and unlikely to cause portability problems.
	
As things stand, Mercury is not portable except to UNIX and Windows systems.
I have provided UNIX code.  I have outlined Windows code.

Note that even if directories were not readable in UNIX, that would not
be a sufficient answer.  There are so *many* ways that the call to 'cat'
in mmake can break, and the mmfind program I posted deals with all of them
that I could think of.  For example, "echo *.d" is perfectly happy to
report dead links and files that are not readable, but "cat" is not happy
to copy them!  Blaming one of the problems (being able to read things you
were not expecting to read) on an operating system which has clearly
documented for over 20 years that this is doable does nothing to address
the other problems.  Writing less than a page of Windows code *would*.

If I had a Windows box, MSVC compiler, and current documentation, it would
have taken me less time to write the code than to write this message.

I'm not quite sure what magic strings .dv, .d, and .dep files should begin
with, but I think it would be a good idea for mmfind to check for that too.

--------------------------------------------------------------------------
mercury-users mailing list
post:  mercury-users at cs.mu.oz.au
administrative address: owner-mercury-users at cs.mu.oz.au
unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-users-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------