Mail Archives: cygwin/2003/01/18/09:16:56
--=-fIU0+fZFBukNZTdFzVBy
Content-Type: multipart/alternative; boundary="=-gxKW2kO4w4xE5ve4upk3"
--=-gxKW2kO4w4xE5ve4upk3
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
An interesting problem. I'm not sure there's a programatic way to solve
it. While spaces are allowed in unix paths, VPATH obviously doesn't
account for this behaviour and assumes spaces are delimiters.. However,
MSDOS/Windows VPATH requires semicolons. I would assume that it does
not allow spaces as a delimiter since they're frequently found in paths
and hence, would break the parse.
"In the VPATH variable, directory names are separated by colons or
blanks. The order in which directories are listed is the order followed
by make in its search. (On MS-DOS and MS-Windows, semi-colons are used
as separators of directory names in VPATH, since the colon can be used
in the pathname itself, after the drive letter.)"
http://www.delorie.com/gnu/docs/make/make_27.html
Good Hunting!
David
On Sat, 2003-01-18 at 05:44, Christopher Seawood wrote:
> Christopher Seawood wrote:
>=20
> > Before: VPATH =3D c:/root/rmch/mozilla/js/src/xpconnect
> > c:/root/rmch/mozilla/js/src/xpconnect/idl
> >=20
> > After: VPATH =3D /cygdrive/c/root/rmch/mozilla/js/src/xpconnect
> > c:/root/rmch/mozilla/js/src/xpconnect/idl
> >=20
> > This implies that the cygwin_win32_to_posix_path_list() function doesn'=
t
> > support converting multiple paths. I haven't grabbed the cygwin dll
> > sources yet. Does anyone know authoritatively if that's the case?
>=20
> After playing around for a bit, I discovered that if I used ; to=20
> separate the dirs instead of a space, then the conversion function=20
> worked fine for all dirs and the other source files were found. This,=20
> of course, breaks the unix builds but I can deal with that.
>=20
> - cls
>=20
>=20
> --
> Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
> Bug reporting: http://cygwin.com/bugs.html
> Documentation: http://cygwin.com/docs.html
> FAQ: http://cygwin.com/faq/
--=20
David Means
C makes it easy for you to shoot yourself in the foot. C++ makes that
harder, but when you do, it blows away your whole leg.
-- Bjarne Stroustrup
--=-gxKW2kO4w4xE5ve4upk3
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; CHARSET=3DUTF-8">
<META NAME=3D"GENERATOR" CONTENT=3D"GtkHTML/1.1.6">
</HEAD>
<BODY>
An interesting problem. I'm not sure there's a programatic way to sol=
ve it. While spaces are allowed in unix paths, VPATH obviously doesn'=
t account for this behaviour and assumes spaces are delimiters.. However, M=
SDOS/Windows VPATH requires semicolons. I would assume that it does n=
ot allow spaces as a delimiter since they're frequently found in paths and =
hence, would break the parse.<BR>
<BR>
"In the VPATH variable, directory names are separated by colons or bla=
nks. The order in which directories are listed is the order followed<BR>
by make in its search. (On MS-DOS and MS-Windows, semi-colons are used as s=
eparators of directory names in VPATH, since the colon can be used in the p=
athname itself, after the drive letter.)"<BR>
<BR>
<A HREF=3D"http://www.delorie.com/gnu/docs/make/make_27.html">http://www.de=
lorie.com/gnu/docs/make/make_27.html</A><BR>
<BR>
Good Hunting!<BR>
<BR>
David<BR>
<BR>
<BR>
On Sat, 2003-01-18 at 05:44, Christopher Seawood wrote:
<BLOCKQUOTE TYPE=3DCITE>
<PRE><FONT COLOR=3D"#050c87" SIZE=3D"3"><I>Christopher Seawood wrote:
> Before: VPATH =3D c:/root/rmch/mozilla/js/src/xpconnect
> c:/root/rmch/mozilla/js/src/xpconnect/idl
>=20
> After: VPATH =3D /cygdrive/c/root/rmch/mozilla/js/src/xpconnect
> c:/root/rmch/mozilla/js/src/xpconnect/idl
>=20
> This implies that the cygwin_win32_to_posix_path_list() function doesn=
't
> support converting multiple paths. I haven't grabbed the cygwin dll
> sources yet. Does anyone know authoritatively if that's the case?
After playing around for a bit, I discovered that if I used ; to=20
separate the dirs instead of a space, then the conversion function=20
worked fine for all dirs and the other source files were found. This,=20
of course, breaks the unix builds but I can deal with that.
- cls
--
Unsubscribe info: </FONT><A HREF=3D"http://cygwin.com/ml/#unsubscribe-=
simple"><FONT SIZE=3D"3">http://cygwin.com/ml/#unsubscribe-simple</FONT></A=
>
<FONT COLOR=3D"#050c87" SIZE=3D"3">Bug reporting: </FONT><A HREF=3D=
"http://cygwin.com/bugs.html"><FONT SIZE=3D"3">http://cygwin.com/bugs.html<=
/FONT></A>
<FONT COLOR=3D"#050c87" SIZE=3D"3">Documentation: </FONT><A HREF=3D=
"http://cygwin.com/docs.html"><FONT SIZE=3D"3">http://cygwin.com/docs.html<=
/FONT></A>
<FONT COLOR=3D"#050c87" SIZE=3D"3">FAQ: </FONT><A HREF=3D=
"http://cygwin.com/faq/"><FONT SIZE=3D"3">http://cygwin.com/faq/</I></FONT>=
</A></PRE>
</BLOCKQUOTE>
<PRE><TABLE CELLSPACING=3D"0" CELLPADDING=3D"0" WIDTH=3D"100%">
<TR>
<TD>
<PRE>--=20
David Means
C makes it easy for you to shoot yourself in the foot. C++ makes that
harder, but when you do, it blows away your whole leg.
-- Bjarne Stroustrup</PRE>
</TD>
</TR>
</TABLE>
</PRE>
</BODY>
</HTML>
--=-gxKW2kO4w4xE5ve4upk3--
--=-fIU0+fZFBukNZTdFzVBy
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iEYEABECAAYFAj4pYckACgkQUd0KwqAz4aoYPgCaAkT23tIO8MUOtmxxzWH6d6zq
ZkQAmwXTaUzhs59rKt3H/ushsxAq0wVD
=6cfj
-----END PGP SIGNATURE-----
--=-fIU0+fZFBukNZTdFzVBy--
- Raw text -