Mail Archives: cygwin/1997/02/12/00:28:13
On Tue, 11 Feb 1997, Griswold, Victor wrote:
> opinion here). What I do know, however, is that neither set of
> filtering
> logic is enabled for the cygwin32 distribution.
That should be fixed by whoever compiles the Cygwin32 tools, IMHO.
> I must admit to my confusion about whether the proper guard is 'WIN32',
> '_WIN32', or '__CYGWIN32__'. There might be a reason for distinguishing
> '__CYGWIN32__', but I fail to see the distinction between 'WIN32' and
> '_WIN32' (except that cygwin32 gcc doesn't pre-define 'WIN32'). Yes,
> this
> is frustrating, and I would welcome objective clarification by someone
> who knows the true distinction between these guard #defines.
I would guess that WIN32 is defined by Microsoft Visual C++ compiler
(which I think was used to port Make 3.75 to Win32). I don't know why
Cygnus doesn't define it, but you can always add it to the predefines
section of your lib/specs file.
> The MSDOS solution for vpath is to use ';' instead of ':' for path
> separators. That is not acceptable to Aironet from a Makefile-portability
> point of view.
You cannot be too portable here, IMHO. If portability is to Unix, then
what would Unix-based Make do with the colons after the drive letters? I
suggest that portable Makefiles should use the ifdef facility, like so
(very crude and untested, but you get the idea):
ifdef COMSPEC
vpath %.c C:/tmp;C:/src/cfiles
endif
ifndef COMSPEC
vpath %.c /tmp:/src/cfiles
endif
I think that, given the existing ports to MSDOS and Win32/MSVC, it's a
bad idea to make the port to Cygwin32 use an entirely different mechanism
for the drive letters. It will make many existing Makefiles be
non-portable between different ports of Make to similar environments,
which is Bad Thing. GNU Make has enough power to make portability
possible with other methods.
-
For help on using this list, send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".
- Raw text -