[M3devel] paths..

[Jay]

It is easier than today I think, and might be made even easier.
Unix doesn't have to be as hard as possible, though I guess I'm a heretic on this point too.
Unix seems to be all about making things much harder than necessary.
 
I am using a workaround for at least some scenarios.
In particular I have some NTFS junctions and some Cygwin symlinks.
Though the symlinks are just for shorter paths and I think unnecessary.
Cygwin symlinks:
 /c => /cygdrive/c 
 /dev2 => /c/dev2 (and then recurse) 
 /cm3 => /c/cm3 (and then recurse) 
 
NTFS junctions: (I use sysinternals.com's junction.exe to set these up) 
  \cygdrive\c => c:\ 
  \c\cm3 => c:\cm3  (aka /c/cm3, on current drive, and win32 accepts forward slashes, voila)  
  \c\dev2 => c:\dev2 (aka /c/cdev2, likewise)  
 
You could also setup in-memory symlinks I believe with subst and/or DefineDosDevice.
 
This way I can cross build either from either.
Just bringing up CM3/Cygwin and "staying there", I don't think requires this. Nor does starting from the distribution I provided,I think. I guess I should test that, and if I am wrong, document these as "officially" needed.
(X86_CYGWIN?, X86_MINGWIN? X86_INTERIX, X86_POSIX_CYGWIN, X86_WIN32_MINGWIN, X86_POSIX_INTERIX?)
 
I also do some path conversion in the Python wrappers.
 
I would strongly consider the following:
 in cm3.exe, set the quake variables INSTALLROOT and ROOT very much like how the Python/sh/Quake code does.
 Something like:
   If the environment variable CM3_ROOT is set, set ROOT to it.
   If the environment variable CM3_INSTALL is set, set INSTALLROOT to it.
     I wouldn't mind while at it coming up with longer more clear names -- CM3_INSTALL_ROOT and CM3_SOURCE_ROOT.
   Convert INSTALLROOT and ROOT to what is native to cm3.exe.
   Possibly write the variables back out to the environment, though that should be not necessary.
   If M3CONFIG is set in the environment, convert it to what is native cm3.exe.
 
   For all this work, only accept full paths. That removes ambiguity since /foo is a valid Win32 path.
 
   If the environment variables are not set, CM3_INSTALL can be gleaned from cm3.exe's own path.
   On Windows this is from GetModuleHandleW(NULL). On other platforms, I guess argv[0]?
   /Possibly/ by searching $PATH for cm3.exe, but that fails if I run cm3.exe by full path and it isn't in $PATH, so no.
 
   CM3_ROOT /maybe/ should not be sniffed out.
   You could do it by checking for CVS directory in current working directory and then going up until CVS/Repository has no slashes, something like that. Yes, I know that is specific to using CVS, doesn't work if you are sitting elsewhere, doesn't work when another source control system is used, etc. But it is very much correct today and fast enough and when it works, is correct (ok..sitting in another CVS tree?) and makes things just a little easier to use. Automation is the name of the game, right? Otherwise we'd all be programming in assembly or ones and zeros.
 
 
 - Jay



> To: wagner at elegosoft.com> Date: Sun, 24 Feb 2008 13:54:34 -0800> From: mika at async.caltech.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] paths..> > Olaf, you're right:> > People who use Cygwin are used to dealing with all kinds of oddities.> > I am here reproducing "README.CYGWIN" from the top level of my M3> project (note the stuff after "IMPORTANT SECTION FOLLOWS"). In my > opinion (and I think of everyone else who appears to use NT386GNU and> also post to this mailing list) the point of Cygwin is to work as a> crutch for Unix people who really, really don't want to use Windows,> but are forced for some (probably economic) reason to do so... We> want as much Unix and as little Windows as possible, and we're willing> to jump through all sorts of hoops to get our way....> > Mika> > > #> # $Id: README.CYGWIN,v 1.3 2007/07/28 23:43:50 mika Exp $> #> > ===== Basic instructions =====> > If you are just building, not maintaining, just > > export CYGWIN=1> > before compiling.> > If you are not building as user "mika", you will have to make some> changes to Make.defs (please look at that file).> > ===== From-Scratch Installation =====> > Installing this system on Cygwin can be a little tricky. So far, it's> only been tested with the old PM3 distribution from Klagenfurt (?).> This PM3 comes on 44 "floppies" and is installed in accordance with the> instructions (in German) located at> > http://www.1o0.de/wi-links/informatik/praxis/programmiersprachen/modula3/installation/windows/windows.html> > Having installed the PM3 distribution, building small, self-contained > Modula-3 programs should be no problem.> > However, it is different with this software distribution. During the> build process, tools are built that are used later on in the same build> process. For various reasons, m3 "overrides" don't seem to work right on> Cygwin/PM3-Klagenfurt, so we build a "distribution" system and m3ship> everything.> > ===== IMPORTANT SECTION FOLLOWS =====> > The main thing that has to be done to simplify the work of the build> system is to make sure that DOS and Cygwin directory paths match AS> MUCH AS POSSIBLE. This is difficult, because by default, Cygwin has> a different view of the "root" of the filesystem from the standard> DOS view. Running under Cygwin, the Klagenfurt system unfortunately> sometimes takes the DOS view and sometimes takes the Cygwin view.> The situation is further complicated by the fact that Windows doesn't> have proper symbolic links.> > The saving grace is that Cygwin DOES have proper symbolic links.> The solution is therefore to make the directory structure that is desired> under DOS and then link to it from within the Cygwin hierarchy.> > Therefore:> > Move the users' home directories to > > C:\home> > and make the links as follows:> > Cygwin link DOS equivalent> /home -> /cygdrive/c/home C:\cygwin\home -> C:\home> > etc.> > The filenames are still occasionally polluted by DOS things like> backslashes and drive letters. The scripts in cygwinhacks should take> care of most of the remaining problems of this sort.> > I am not sure this system can be made to work if your system disk> is called anything other than C:. Best not to try.> > (end of README.CYGWIN)> > Olaf Wagner writes:> >Jay,> >> >I'm not really happy with NT386GNU using PathnameWin32.m3.> >In my opininion it should just use the POSIX code, whatever problems> >people will have with their installation roots. (These can be avoided> >by using the /cygdrive/... equivalents.)> >Why don't we just assume that by deafult CM3 is installed in> >/usr/local/cm3 as for all other targets (except NT386, of course)?> >> >One thing that immediately comes to mind is that all paths output> >by CM3 programs will contain \ instead of / then and thus be> >unusable for simple copy-and-paste, as \ is the escape character> >in all POSIX command line tools. So this seems kind of incompatible> >to me.> >> >Olaf> >> >Quoting Jay <jayk123 at hotmail.com>:> >> >> I could be wrong about many things here:> >>> >> Cygwin fopen and I presume open accepts all of:> >> c:\foo, c:/foo, /foo, \foo> >>> >> /foo and \foo probably have a different meaning between Cygwin and Win32.> >> In Win32, /foo and \foo are, well, \foo, on the current drive.> >> In Cygwin, /foo is probably /foo at the Cygwin root.> >> I'd kind of like to be wrong here, about \foo having different > >> meanings between them, since it a common form for me.> >>> >> Cygwin does not accept c:foo.> >> In Win32 c:foo is foo in the current working directory of the C: drive.> >> I don't think c:foo is used often, but it does have a meaning.> >>> >> Now, as well, cm3 has its own Path module, M3Path, but I realized > >> tonight it also uses libm3's Pathname module a fair amount. In > >> particular, I was having errors "shipping".> >>> >> This throws a big monkey wrench into where I was going.> >> So now, after a bunch of going back and forth on various uncommited > >> changes, I have now switched (and commited) NT386GNU to use > >> PathnameWin32.m3. To some extent, this strikes at the core of "what > >> is Posix" and "ruins" NT386GNU's differentiation from "NT386MINGNU". > >> However, remember that Cygwin does appear to accept Win32 paths. > >> So, again, if Cygwin accepts Win32 paths, is it Posix? (Given that > >> Win32 accepts /foo, is it Posix?) As well, this target still uses > >> cygwin1.dll for its all its odd behaviors. It still uses > >> open/read/write (again, remember that msvcrt.dll DOES expose these > >> SAME functions..I still contend that Win32 is close enough to Posix > >> to satisfy almost everyone..and then X Windows can be dealt with > >> separately maybe, or Trestle/Win32 fixed).> >>> >> I have some more testing to do but I think this switch will fly, and > >> various other options can go away.> >> And I can undo the small amount I had commited.> >> I think I'll just send my m3path.m3 diff around and then delete it.> >>> >> I ended up with a set based approach where host and target have a > >> set of dir separaters, volume separaters, and separators (union of > >> previous two). These are TINY sets, containing a maximum of three > >> characters each, and '/' is always a member of two of them. So a set > >> is kind of overkill. But it works out pretty ok.> >>> >> - Jay> >> _________________________________________________________________> >> Need to know the score, the latest news, or you need your > >> Hotmail®-get your "fix".> >> http://www.msnmobilefix.com/Default.aspx> >> >> >> >-- > >Olaf Wagner -- elego Software Solutions GmbH> > Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany> >phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> > http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin> >Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
_________________________________________________________________
Climb to the top of the charts! Play the word scramble challenge with star power.
http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080225/388e72fa/attachment-0002.html>