[M3devel] [M3commit] CVS Update: cm3

[Jay]

I'm going to work on this more but not today.
I will at least restrict it to check that the next character is a slash.
I'm not sure that will satisfy folks.
The Pathname module is/was being used but is a little unsatisfactory. > I use colons in filenames a lot 
 
Do you use it in source files?
For "root" directories, like where your cm3 install/source is?
 
I'm trying to think/wiggle through what might be an acceptable escape.
Something like -- where files in general are vs. where "programmer" files are.
Putting a colon in a filename really is quite non-portable.
And that may or may not matter.
 
The existing Modula-3 code was fairly strict and I very unsure it was right.
I had a question drafted to m3devel that I ended up not sending.
It went roughly like:
"
  Has anyone done a cross build where host and target vary in naming conventions?
  I am skeptical that this works, and am strongly considering /slightly/ depending on that
    or making it "worse". In particular, there is provision in the code for "converting"
    between host and target paths, but all it does is translate slashes. It doesn't
    translate libfoo.a to foo.lib for example.
"
 
Upon further digging though, I decide that my more immediate severe problem
could be dealt with not by making things worse but by making them better.
This is the change around checking NAMING_CONVENTIONS earlier.
While my analysis was not 100% thorough, it is my very strong suspicion
that the NAMING_CONVENTION and undocumented TARGET_NAMING configuration
variables never really worked. Sure, they affected the name of the .m3x file.
But that is about it. I didn't check .exes, but probably didn't work, and what I was
seeing was they didn't work for libraries.
 
M3Path.m3 sets up one set of path data in three ways.
  variable initialization (VAR foo := 123)
  module initialization (BEGIN foo := 456 END Module.) 
  and explicit calls after reading the config file 
 
The problem was that the explicit calls were very late, so the module initialization is what held.
If Join(a,b) == a/b, then you'd get Unix naming conventions.
/Arguably/ this is exactly correct.
But I would like the slash and the "naming" to be separate, at least for now.
That is, NT386GNU uses forward slashes but foo.lib instead of libfoo.a.
I should try to change that actually.
I had trouble changing it for this reason since I was cross building from NT386.
 
The NT386 HOST wants to use Win32 naming conventions, "\" and foo.lib, even
if the config file asks for Unix naming..
 
Anyway, this is all somewhat of a tangent, one in which I'm more confident of where to go
  and that what I changed is ok. (It might become irrelevant.)
 
The other issues are around "difficulty" setting paths.
I had CM3_ROOT=c:\dev2\cm3.2.
That wouldn't necessarily work with NT386GNU.
 
It seems darn near possible to have one path syntax and one set of code for dealing with it.
But maybe not.
Even semicolon vs. colon seems doable. Specifically, if an element of $PATH appears to be just a single character, that colon is not a $PATH divider.
 
Perhaps I just need to have two sets of CM3_ROOT / CM3_INSTALL and perhaps M3CONFIG variables.
I was kind of hoping not.
 
It's worse than that really, since the two hosts can target the two targets, so host and target paths needs to be better distinguished than I believe the are now. I was saying there is code to change the slashes, but there isn't code to deal with a leading drive letter.
 
What I have been particularly avoiding is calls out to cygwin_convert_path or such, but maybe that's what I need to do.
 
Get ROOT / CM3_INSTALL etc. from the command line and environment, convert as appropriate, and move on.
 
ROOT in particular is set by Python. Usually for me that is Win32 Python, but Cygwin Python is an option.
So then Python has to know what cm3 it is running?
I considered probing it with findstr /i /m cm3.exe cygwin1.dll.
I considered something like cm3 -report_something_or_other, kind of like gcc has -print-gcc-lib-name or whatnot.
 
These might still be viable ideas.
 
Historically cross environments don't allow multiple "targets" / "platforms" / "configurations" / "whatever" to run on the same OS. But there is some of an opposite trend. Like how NT386 and NT386GNU run on the same OS. Like SOLsun, SOLgnu. Like x86 on AMD64 operating systems. So maybe a little bit of support is good there, the cm3 -print-slash or cm3 -print-host or something.
 
Also I forgot to point out that Win32 is often find with forward slashes, but notable file.open dialogs are not.
I very frequently copy compiler output to file.open dialogs so in some places backward slashes are preferred.
A possible strategy is to sniff what the user is using -- such as in any of those environment variables -- and favor it.
Or for each Join operating harvest a path separater from the parameters and default if there is none there.
 
I have some code working like that last option right now but it's not quite working and has to wait.
 
It is very reasonable to have Win32 treat forward and backward slashes as the same, in particular.
It is fairly reasonable imho for Posix code to also treat them the same but "fixup" backward to forward.
 
As well, on Windows, if you mostly limit yourself to one drive letter, then /foo/bar is a pretty acceptable form..
 
Anyway...lots of facts, some easy conclusions, some unclear conclusions.
I'll fiddle around with it more later.
Ideally switching between NT386 and NT386GNU is fairly easy..
 
 - Jay



> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > Date: Mon, 18 Feb 2008 14:04:06 -0800> From: mika at async.caltech.edu> > > I never tried putting it in my PATH, no... You are right, colons> are *slightly* special. I am not in the habit of copying files to> Windows. I only copy files between Unix and Windows to save them> from Windows.> > That being said, I am pretty sure I use colons more in filenames> than I use the letter "q". Could you ban the letter "q" instead? :)> > If you've gotta do it, then do it. It's just ... weird.> > I personally will probably never run into the issue. I use colons> in filenames a lot, but as a separator for various types of data> files. <data source>:<data details>.<extension>> > Is your code able to import (or duplicate...) Pathname? I would> have thought that that interface has all the necessary bits to make> paths portable...> > MIka> > Jay writes:> >--_dfd4e29a-b904-43be-8435-4824d419d270_> >Content-Type: text/plain; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >> But colons? Colons are not special in any way, shape, or form, on> Unix..=> >. I think "it is extremely surprising" to a Unix user if a path> >Ever try putting a path with a colon into $PATH? Does it work?> >Or copying a file with a colon in its name to a Windows system? Does it wor=> >k?> >This part could be limited to systems that have $OS =3D=3D Windows_NT I gue=> >ss.> >=20> >As a user switching between multiple systems, this area is quite frustratin=> >g...I guess no matter what.> >Sometimes one form works, sometimes another, sometimes either, often with i=> >dentical meaning, but not always.> >These changes, and about one more, should make building NT386GNU a fair amo=> >unt easier..> >=20> >Currently it is any path with a colon in the second character.> >How about if that is further restricted to having a-z in the first characte=> >r and/or more importantly a slash in the third character?> >=20> > - Jay> >> >> >
_________________________________________________________________
Helping your favorite cause is as easy as instant messaging. You IM, we give.
http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080218/fccb139c/attachment-0002.html>