<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>There's no dependency, no linkage. Just a few simple string operations.<BR>
I'll probably remove it tonight.<BR>
<BR>
Modula-3 has a split personality no matter what, in that it calls into very varying underlying layers, often trafficing in their specific data formats.<BR>
It's just that it can strive to aid portability between them or not, by accepting either input and massaging it to work, vs. passing it along "unchanged" (well, that's not what happens actually). If there were no ambiguous cases and the Posix systems on Windows were consistent in their conventions, I'd be more for it. But the ambiguity and varying Posix conventions weaken the case tremendously.<BR>
<BR>
- Jay<BR><BR>
<BLOCKQUOTE>
<HR id=EC_stopSpelling>
Date: Mon, 21 Apr 2008 23:14:00 -0400<BR>From: rcoleburn@scires.com<BR>To: m3devel@elegosoft.com<BR>Subject: Re: [M3devel] more path stuff, sorry<BR><BR>
<META content="Microsoft SafeHTML" name=Generator>
<DIV>I concur wholeheartedly. I absolutely DO NOT want native NT386 to have any knowledge of or dependency on Cygwin.</DIV>
<DIV>Regards,</DIV>
<DIV>Randy<BR><BR>>>> Tony Hosking <hosking@cs.purdue.edu> 4/21/2008 9:44 PM >>><BR></DIV>
<DIV><SPAN class=EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate">
<DIV style="WORD-WRAP: break-word"><SPAN class=EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate"><SPAN class=EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate"><SPAN class=EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate"><SPAN class=EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate"><SPAN class=EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate"><SPAN class=EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate"><SPAN class=EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate"><SPAN class=EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate">
<DIV>Why would native NT386 know anything at all about Cygwin. I say just avoid split personalities like the plague. Similarly, I'd be happy for NT386GNU (i.e., Cygwin?) to simply behave like a POSIX build (modulo native threads perhaps).</DIV></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></DIV></SPAN></DIV><BR>
<DIV>
<DIV>On Apr 21, 2008, at 7:15 PM, Jay wrote:</DIV><BR class=EC_Apple-interchange-newline>
<BLOCKQUOTE><SPAN class=EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate">
<DIV class=EC_hmmessage style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">Maybe this is dubious.<BR><BR>The question is, like, should native NT386 cm3 accept /cygdrive/c/foo and translate to c:\foo?<BR>Or trickier, /usr/bin/foo and translate to c:\cygwin\usr\bin\foo?<BR>And vice versa, should NT386GNU accept c:\foo?<BR><BR>The translation is not simple in general.<BR>/ maps to the Cygwin install root.<BR>There can be symlinks.<BR>But many common cases can be handled with little, simple code.<BR>It's already in.<BR><BR>Ultimately the way to do this correctly is to link to cygwin1.dll, which is only done sometimes,<BR> and which probably license-undesirable when not done.<BR><BR>As well, a path like /foo is actually ambiguous.<BR>It is a valid native Win32 path, equivalent to \foo.<BR>Or it could be Cygwin path requivalent to c:\cygwin\foo.<BR><BR>While it is nice to keep cm3 simple, it is also nice to have a more uniform interface<BR>across hosts, I think. Maybe.<BR><BR>To some extent a user can do this himself.<BR>That is, NTFS junctions and/or Cygwin symblinks can cause their to be identical paths<BR>with identical meanings:<BR>e.g. for me, symlink /msdev => c:\msdev, /cm3 => c:\cm3 /dev => c:\dev2<BR><BR>In some places Cygwin open et. al. accept Win32 paths, but lately taking advantage of<BR>that issues a warning. In some places, I think, it isn't sufficient to have Cygwin handle it.<BR><BR>The harder question then is, if I feed Cygwin paths of a particular form, should it<BR>try to report back paths in the same form?<BR><BR>I put some code in M3Path.m3 "like this", but it may not be advisable.<BR><BR>I also had an NTFS junction on my system so Win32 /cygdrive/c => c:\, but this causes<BR>a circularity in the file system, which I'd rather not have.<BR><BR>As well, there are at least three or four Posix runtimes for Windows, and they each map<BR>differently.<BR><BR>UWin I think uses /c <=> c:\.<BR>Cygwin /cygdrive <=> c:\<BR>Interix/ServicesForUnix/SUA I think something via /dev.<BR>MinGWin also has a runtime that I think uses the UWin mapping, but this runtime is only<BR>meant for sh/gcc to use, not user apps.<BR><BR>Having special code that only knows the Cygwin convention is questionable.<BR> <BR>I was often setting up some environment variables one way or the other, and then<BR>running one cm3 or the other, without thinking about which form the variables were in.<BR>Indeed, it might be nice to set<SPAN class=EC_Apple-converted-space> </SPAN><FONT face="">CM3_ROOT</FONT><SPAN class=EC_Apple-converted-space> </SPAN>and<SPAN class=EC_Apple-converted-space> </SPAN><FONT face="">CM3_INSTALL</FONT><SPAN class=EC_Apple-converted-space> </SPAN>"once and for all",<BR>while still switching between different forms of cm3.exe?<BR>Though granted,<SPAN class=EC_Apple-converted-space> </SPAN><FONT face="">CM3_INSTALL</FONT><SPAN class=EC_Apple-converted-space> </SPAN><FONT face="">cm3.exe</FONT><SPAN class=EC_Apple-converted-space> </SPAN>can usually figure out from its own path, and<BR><FONT face="">CM3_ROOT</FONT><SPAN class=EC_Apple-converted-space> </SPAN>could usually be figured out by looking at the CVS directories in the current<BR>working directory, not always, but often. Basically, instead of setting these varibles<BR>one way or the other, I'd like to set them always one way, or even not at all.<BR><BR><BR>Hm, in fact, I think cm3 could figure out all overrides itself?<BR>You know, if there is a shipped package store, it can use that to determine the source <=> pkg mapping.<BR>And it can figure out CM3_ROOT by looking at the current directory and on up until the CVS/Root<BR>changes?<BR> <BR>As well, you know, the source <=> pkg mapping could be a simple generated checked in file.<BR>You know, like the PKGS file, but stripped down to only what is needed?<BR> <BR>Maybe just remove the code I put in and forget the whole thing.<BR>Maybe most people only ever stay in one of the worlds and "translation" isn't important?<BR>Just me stuck with providing support for both and therefore living with both more?<BR> <BR> <BR> - Jay<BR></DIV></SPAN></BLOCKQUOTE></DIV><BR></BLOCKQUOTE></body>
</html>