Mail Archives: cygwin/2000/04/19/11:47:39
------_=_NextPart_001_01BFAA1E.9A71150A
Content-Type: text/plain;
charset="iso-8859-1"
From Bernard
> From Brian
>> Okay, I'm sure of what caused this now. The Makefile look
>> something like
>> this.
>>
>> #--begin Makefile---
>> SOMEVAR=$(ANOTHERVAR)/etc
>> include $(DEVDIR)/Makefile.mstr
>> #--end Makefile---
>>
>> DEVDIR is defined in the environment. ANOTHERVAR however is
>> defined in the
>> included makefile. I thought make was supposed to try to do
>> full expansion
>> on a second read of the makefile? Seems to have worked before.
>
> In fact make is suppose to expand SOMEVAR only when it sees
> $(SOMEVAR), so
> yo u only have to be sure that ANOTHERVAR is set before trying to use
> SOMEVAR. However be careful: if SOMEVAR is used in a
> dependency (either
> target or dependant part), it will be expanded as soon as it is seen.
So I went off and tried to duplicate my problem with the smallest Makefile
possible and have succeeded. Turns out the problem is with a target macro's
value indicating a dos style filename, e.g. e:/dir/file (yes, with UNIX
slashes) even with MAKE_MODE=UNIX set in the environment. Using something
like //e/dir/file works of course. I think that on win32 e:/dir/file is
supposed to be allowed without confusing the make parser but I cannot find
much in the info documentation to help make this clearer (it did work in the
past with make 3.75, the cygwin 1.1 net release uses 3.77).
From make.info 3.77...
Microsoft operating systems (MS-DOS and MS-Windows) use backslashes
to separate directories in pathnames, like so:
c:\foo\bar\baz.c
This is equivalent to the Unix-style `c:/foo/bar/baz.c' (the `c:'
part is the so-called drive letter). When `make' runs on these
systems, it supports backslashes as well as the Unix-style forward
slashes in pathnames. However, this support does *not* include the
wildcard expansion, where backslash is a quote character. Therefore,
you *must* use Unix-style slashes in these cases.
--- end excerpt from info
Ideas? I've cc'd bug-make AT gnu DOT org.
Brian
------_=_NextPart_001_01BFAA1E.9A71150A
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2651.65">
<TITLE>RE: New Cygwin Net Release (make error)</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=3D2>From Bernard</FONT>
<BR><FONT SIZE=3D2>> From Brian</FONT>
<BR><FONT SIZE=3D2>>> Okay, I'm sure of what caused this =
now. The Makefile look </FONT>
<BR><FONT SIZE=3D2>>> something like</FONT>
<BR><FONT SIZE=3D2>>> this. </FONT>
<BR><FONT SIZE=3D2>>> </FONT>
<BR><FONT SIZE=3D2>>> #--begin Makefile--- </FONT>
<BR><FONT SIZE=3D2>>> SOMEVAR=3D$(ANOTHERVAR)/etc </FONT>
<BR><FONT SIZE=3D2>>> include $(DEVDIR)/Makefile.mstr </FONT>
<BR><FONT SIZE=3D2>>> #--end Makefile--- </FONT>
<BR><FONT SIZE=3D2>>> </FONT>
<BR><FONT SIZE=3D2>>> DEVDIR is defined in the environment. =
ANOTHERVAR however is </FONT>
<BR><FONT SIZE=3D2>>> defined in the</FONT>
<BR><FONT SIZE=3D2>>> included makefile. I thought make was =
supposed to try to do </FONT>
<BR><FONT SIZE=3D2>>> full expansion</FONT>
<BR><FONT SIZE=3D2>>> on a second read of the makefile? =
Seems to have worked before. </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> In fact make is suppose to expand SOMEVAR only =
when it sees </FONT>
<BR><FONT SIZE=3D2>> $(SOMEVAR), so</FONT>
<BR><FONT SIZE=3D2>> yo u only have to be sure that ANOTHERVAR is =
set before trying to use</FONT>
<BR><FONT SIZE=3D2>> SOMEVAR. However be careful: if SOMEVAR is used =
in a </FONT>
<BR><FONT SIZE=3D2>> dependency (either</FONT>
<BR><FONT SIZE=3D2>> target or dependant part), it will be expanded =
as soon as it is seen.</FONT>
</P>
<P><FONT SIZE=3D2>So I went off and tried to duplicate my problem with =
the smallest Makefile possible and have succeeded. Turns out the =
problem is with a target macro's value indicating a dos style filename, =
e.g. e:/dir/file (yes, with UNIX slashes) even with MAKE_MODE=3DUNIX =
set in the environment. Using something like //e/dir/file works =
of course. I think that on win32 e:/dir/file is supposed to be =
allowed without confusing the make parser but I cannot find much in the =
info documentation to help make this clearer (it did work in the past =
with make 3.75, the cygwin 1.1 net release uses 3.77).</FONT></P>
<P><FONT SIZE=3D2>From make.info 3.77...</FONT>
</P>
<P><FONT SIZE=3D2> Microsoft operating systems (MS-DOS and =
MS-Windows) use backslashes</FONT>
<BR><FONT SIZE=3D2>to separate directories in pathnames, like =
so:</FONT>
</P>
<P><FONT SIZE=3D2> =
c:\foo\bar\baz.c</FONT>
</P>
<P><FONT SIZE=3D2> This is equivalent to the Unix-style =
`c:/foo/bar/baz.c' (the `c:'</FONT>
<BR><FONT SIZE=3D2>part is the so-called drive letter). When =
`make' runs on these</FONT>
<BR><FONT SIZE=3D2>systems, it supports backslashes as well as the =
Unix-style forward</FONT>
<BR><FONT SIZE=3D2>slashes in pathnames. However, this support =
does *not* include the</FONT>
<BR><FONT SIZE=3D2>wildcard expansion, where backslash is a quote =
character. Therefore,</FONT>
<BR><FONT SIZE=3D2>you *must* use Unix-style slashes in these =
cases.</FONT>
</P>
<P><FONT SIZE=3D2>--- end excerpt from info</FONT>
</P>
<P><FONT SIZE=3D2>Ideas? I've cc'd bug-make AT gnu DOT org. =
</FONT>
</P>
<P><FONT SIZE=3D2>Brian</FONT>
</P>
</BODY>
</HTML>
------_=_NextPart_001_01BFAA1E.9A71150A--
- Raw text -