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

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

Mr. Zaretskii:

>From: Eli Zaretskii
>To: Griswold, Victor
>Cc: gnu-win32@cygnus.com; bug-gnu-utils@prep.ai.mit.edu
>Subject: Re: Make 3.75: Win32-Specific Fix for Filenames in
Dependencies and i n Vpath
>Date: Tuesday, February 11, 1997 2:36AM
>
>On Mon, 10 Feb 1997, Griswold, Victor wrote:
>
>>...
>
>I think Make 3.75 already supports colons in pathnames.  There should
be
>WIN32- and DOS-specific code in Make that allows using `:' without any
>escape characters.  Can you post a short Makefile which exhibits the
>problems you are trying to solve and see why doesn't it work with the
>released version of Make 3.75?  What compiler did you use to build
Make?

The source distribution I used was directly from the cygwin32 'cdksrc'
source
tree of Beta 17.1.  Both the officially distributed binaries and the
locally-
rebuilt binaries (rebuilt with the version of gcc cygnus-2.7.2-961023
distributed with cygwin32 Beta 17.1) exhibited the undesirable
':'-related
behavior identically.

Yes, in 'read.c' there is logic in 'parse_file_seq' to avoid leading
drive
letters such as 'C:\' or 'C:/'.  This logic is not enabled by the tools
provided in Beta 17.1, which evidently pre-define '_WIN32' instead of
'WIN32'.  I could have chosen to enable this logic, rather than the
VMS-like
logic, with an additional check for '_WIN32'.  However, doing so would
have
made the solution inconsistent with that for vpath.  Perhaps a more
robust
approach would be to enable _both_ filters for ':' in filenames, but I
think
that the "escaped" approach is more conservative (I have no really
strong
opinion here).  What I do know, however, is that neither set of
filtering
logic is enabled for the cygwin32 distribution.

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.

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.  Simply fixing 'parse_file_seq' will not fix
'construct_vpath_list', because 'construct_vpath_list' does its own
parsing
without calling 'parse_file_seq'.


An example Makefile which exhibits the vpath behavior is:

 ----start
vpath_test.mak-------------------------------------------------
vpath %.c C:/tmp

all:
	echo 'vpath_test.mak'
 ----end vpath_test.mak-------------------------------------------------

Test the operation of 'make' with 'make -p -f vpath_test.mak'.
Substitute
'C\:' for 'C:' in the above file and test with the original and modified
versions of 'make' to see the differences (make sure there is a
'C:\tmp',
of course).


An example Makefile which exhibits the dependency behavior is:

 ----start
depend_test.mak-------------------------------------------------
hello.o : C:/tmp/hello.c
	gcc -o hello $^
 ----end
depend_test.mak-------------------------------------------------

Test the operation of 'make' with 'make -f depend_test.mak', after
creating
a "hello, world" file in 'C:\tmp\hello.c'.  Substitute 'C\:' for 'C:' in
the
above file and test with the original and modified versions of 'make' to
see the differences.

I hope the above helps, or at least adds some clarification.  If I'm
going
about this all wrong, please let me know.  Thanks for the feedback!


Victor J. Griswold, D.Sc.
Aironet Wireless Communications, Inc.
voice:	330-664-7987
fax:	330-664-7301
email:	(MS-Mail) vgris@aironet.com
	(MIME) Victor.Griswold@pobox.com

-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".