<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>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 <FONT face="">CM3_ROOT</FONT> and <FONT face="">CM3_INSTALL</FONT> "once and for all",<BR>
while still switching between different forms of cm3.exe?<BR>Though granted, <FONT face="">CM3_INSTALL</FONT> <FONT face="">cm3.exe</FONT> can usually figure out from its own path, and<BR><FONT face="">CM3_ROOT</FONT> 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></body>
</html>