[M3devel] paths..

[Mika Nystrom]

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