[M3devel] more path stuff, sorry

[Tony Hosking]

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).

On Apr 21, 2008, at 7:15 PM, Jay wrote:

> Maybe this is dubious.
>
> The question is, like, should native NT386 cm3 accept /cygdrive/c/ 
> foo and translate to c:\foo?
> Or trickier, /usr/bin/foo and translate to c:\cygwin\usr\bin\foo?
> And vice versa, should NT386GNU accept c:\foo?
>
> The translation is not simple in general.
> / maps to the Cygwin install root.
> There can be symlinks.
> But many common cases can be handled with little, simple code.
> It's already in.
>
> Ultimately the way to do this correctly is to link to cygwin1.dll,  
> which is only done sometimes,
>  and which probably license-undesirable when not done.
>
> As well, a path like /foo is actually ambiguous.
> It is a valid native Win32 path, equivalent to \foo.
> Or it could be Cygwin path requivalent to c:\cygwin\foo.
>
> While it is nice to keep cm3 simple, it is also nice to have a more  
> uniform interface
> across hosts, I think. Maybe.
>
> To some extent a user can do this himself.
> That is, NTFS junctions and/or Cygwin symblinks can cause their to  
> be identical paths
> with identical meanings:
> e.g. for me, symlink /msdev => c:\msdev, /cm3 => c:\cm3 /dev => c: 
> \dev2
>
> In some places Cygwin open et. al. accept Win32 paths, but lately  
> taking advantage of
> that issues a warning. In some places, I think, it isn't sufficient  
> to have Cygwin handle it.
>
> The harder question then is, if I feed Cygwin paths of a particular  
> form, should it
> try to report back paths in the same form?
>
> I put some code in M3Path.m3 "like this", but it may not be advisable.
>
> I also had an NTFS junction on my system so Win32 /cygdrive/c => c: 
> \, but this causes
> a circularity in the file system, which I'd rather not have.
>
> As well, there are at least three or four Posix runtimes for  
> Windows, and they each map
> differently.
>
> UWin I think uses /c <=> c:\.
> Cygwin /cygdrive <=> c:\
> Interix/ServicesForUnix/SUA I think something via /dev.
> MinGWin also has a runtime that I think uses the UWin mapping, but  
> this runtime is only
> meant for sh/gcc to use, not user apps.
>
> Having special code that only knows the Cygwin convention is  
> questionable.
>
> I was often setting up some environment variables one way or the  
> other, and then
> running one cm3 or the other, without thinking about which form the  
> variables were in.
> Indeed, it might be nice to set CM3_ROOT and CM3_INSTALL "once and  
> for all",
> while still switching between different forms of cm3.exe?
> Though granted, CM3_INSTALL cm3.exe can usually figure out from its  
> own path, and
> CM3_ROOT could usually be figured out by looking at the CVS  
> directories in the current
> working directory, not always, but often. Basically, instead of  
> setting these varibles
> one way or the other, I'd like to set them always one way, or even  
> not at all.
>
>
> Hm, in fact, I think cm3 could figure out all overrides itself?
> You know, if there is a shipped package store, it can use that to  
> determine the source <=> pkg mapping.
> And it can figure out CM3_ROOT by looking at the current directory  
> and on up until the CVS/Root
> changes?
>
> As well, you know, the source <=> pkg mapping could be a simple  
> generated checked in file.
> You know, like the PKGS file, but stripped down to only what is  
> needed?
>
> Maybe just remove the code I put in and forget the whole thing.
> Maybe most people only ever stay in one of the worlds and  
> "translation" isn't important?
> Just me stuck with providing support for both and therefore living  
> with both more?
>
>
>  - Jay

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080421/588dcbdc/attachment-0002.html>