[M3devel] more path stuff, sorry

[Jay]

The split personality has to be somewhere -- either in the user of both or in the code.
But maybe there are no users of both. :)
Ok, they are it.
I'll remove the code, and see how my experience fairs, and try to keep the results to myself. :)
 
 > Why would native NT386 know anything at all about Cygwin
 
It depends on why someone choses the one cm3 or the other.
If a user "likes Unix" but finds gcc too slow, he might be passing Cygwin paths to the native compiler.
If a user "likes Windows" but really wants 64 bit integers right now, he might be inclined to pass Win32 paths to the Cygwin compiler.
Granted, the second user could also use NT386MINGNU (__stdcall still broken, I should be able to fix or workaround.)
As well, um, the first user could make up a configurationi that suites actually.
That is, the choice of backend and the choice "what runtime cm3 uses" are two independent variables.I am answering my question though -- all four combinations should work, and three of them even have names.
 
Mostly user doesn't care "what runtime in use", but user could easily care about the command lines accepted.
And, you know, accepting different path forms..doesn't really require cygwin.
If the inputs are human generated, he/she can probably live with c:/foo, or /c/foo and make a junction -- c:\c\foo => c:\foo.
Oh that second one is a new idea to me actually.
 
I should type that up -- "Windows paths for people that like forward slashes".
 
Again, I know I'm a broken record, but it comes down to what someone wants in "NT386GNU".
And the host and target are independently configurable, mostly, maybe -- NT386 can output NT386GNU and vice versa.
User might like backward slashes but need to produce code that works in a more Posixish environment.
This is like a cross build, except both targets run on the same OS.
 
It probably just comes down what we have -- the two or three canned config files, and someone that wants to mix and match differently can do so. The toplevel NT386/NT386GNU/NT386MINGNU are small thin easily rewritten wrappers over NT386.common anyway. User can provide his own.
 
At some hypothetical point, that will probably never arrive, config files should be tried out for Borland, Watcom, Digital Mars, and ideally, they follow this same pattern -- managing to get by with no compiler change and no new target, just a config file, possibly growing the jmpbuf to the largest of them, if that isn't too large. Actually the compiler doesn't do this correctly. I think it assumes the external backend targets one jumpbuf size and integrated one another. This should either be a dangerous integer directly set in the config file, or keyed off the "CRuntime" parameter there, values like MS, GNU, WATCOM, MWERKS, DMARS. It could be more configuration knobs make sense, since Windows compilers tend to have so many switches, the M3 compiler might have to know more stuff, to interoperate. Anyway..I'm skeptical these targets/configs would have any customers..on to other stuff for now. :)
 
This reminds me of maybe a more important problem -- discerning host and target, I'll start a separate thread.
 
 - Jay
 



CC: m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] more path stuff, sorryDate: Mon, 21 Apr 2008 21:44:17 -0400



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 interfaceacross 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 pathswith identical meanings:e.g. for me, symlink /msdev => c:\msdev, /cm3 => c:\cm3 /dev => c:\dev2In some places Cygwin open et. al. accept Win32 paths, but lately taking advantage ofthat 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 ittry 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 causesa 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 mapdifferently.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 onlymeant 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 thenrunning 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, andCM3_ROOT could usually be figured out by looking at the CVS directories in the currentworking directory, not always, but often. Basically, instead of setting these variblesone 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/Rootchanges? 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/20080422/30ad7ee5/attachment-0002.html>