Re: Make 3.75: Win32-Specific Fix for Filenames in Dependencies a nd i n Vpath

["Griswold, Victor" <VGris at aironet dot com>]

Mr Zaretskii:

>> 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 agree.  And one of the groups which compiles the Cygwin32 tools is
Cygnus, for their standard distribution.  Part of the testing of the
Beta release of Cygwin32 is checking the assertion that the tools are
self-hosting as distributed and claimed.  If one needs to add additional
compilation options after running 'configure' in order to build
functioning tools, then the self-hosting capability needs to be updated
accordingly.  It is a minor fix to correct a problem; nothing to get
upset about.

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

See above comment about not needing to modify makefiles to reproduce the
distribution after running 'configure'.

>> 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):

You do not understand the build environment.  The only place drive
letters can get introduced is through environment variables which point
to the absolute path for source, the absolute path for a given build,
etc.  There are no drive letters in the Makefiles themselves.  Use of
conditionals in Makefiles is unnecessary, cluttering, and error-prone,
especially when having to take into account multiply-nested variables
and string operations on them.

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

This is a semi-"religious" issue of which is more important:
compatibility between MSDOS/MSVC Makefiles with Cygwin32, or
compatibility between Unix Makefiles with Cygwin32.  I do not intend to,
and _will_ not, open up another "Text vs. Binary" file issue here.  All
I can say is that we have a locally-significant reason to emphasize
porting our Unix environment to WinNT with as little modification as
possible.  I doubt that Aironet is unique in that regard, and I believe
that there might be some other organizations which would find the
provided patches useful.  I also believe that there are other
organizations which have already made use of pre-Cygwin32 ports of Make
to MSDOS/MSVC and feel that compatibility with those other ports of Make
is most important.  Freedom of choice is a Good Thing when available.

The issue which brought this discussion up is that, currently, the B17.1
distribution of the Cygwin32 tools satisfies neither group of users
without modification either to the build procedure or to the source code
itself.  It would appear that something needs to be corrected in order
to get closer to the (now very close) dream of a Unix-like environment
under Win32.  Cygnus is doing the whole software development community a
great favor by working on Cygwin32; what little we can do to help that
along, we do.

Next to release:  RCS 5.7 and CVS 1.9 for Cygwin32, which pass the
validation suites and allow the same repositories to be used by both
Unix and WinNT clients.


Victor J. Griswold, D.Sc.
 Aironet Wireless Communications, Inc.
 voice:	330-664-7987
 fax:	330-664-7301
 email:	vgris@aironet.com
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".