[M3devel] some more notes on the win32 system

[Jay]

I don't setup stuff with spaces mostly, but it doesn't matter.
 
In the past, as the install and configuration nudged you, cminstall/cm3.exe/cm3.cfg trafficed in the full paths to cl.exe, link.exe, various .libs, and possibly directories containing .h.
 
In the present, cm3.cfg invokes merely "cl" or "cl.exe", "link" or "link.exe", does not pass any include paths to the compiler, and passes leaf file names of .libs to the linker -- msvcrt.lib, kernel32.lib, etc.
 
If course there must be another side to that.
"vcvars32.bat" and such sets %PATH% so that cl and link are on it, sets %INCLUDE% so that the various headers are on it, and %LIB% so that various .libs are on it.
 
My sysinfo.cmd also prepends %ROOT%\lib or whatever to %LIB%, as cm3\m3-win\import-libs makes our own import .libs, since some toolsets, like at least the 7.1 Express Edition and I think 8.0, lack most the usual import .libs -- like they are enough for managed CLR development and "stdio" development, but not native Win32 development. The Platform SDK is also a free download, so I'm not replacing something you can't get for free, but it saves you an extra download and install, perhaps.
 
There are pluses and minuses to this arrangement.
 
I guess you can point cm3.exe at a specific cm3.cfg file? I never do that. Rather than have n different configurations, I have one configuration but vary the environment variables.
The downside is that in a "bare" environment, nothing works.
Unless you go and foist the vcvars32.bat onto your default environment.
 
There is large general problem around settings, state, install (sometimes called "deployment) that has yet to be solved to most people's satisfaction. This is very much related to that. Environment variables are an ancient crude mechanism, lacking in type, lacking in hierarchy. Their main claims to fame include a) basically the same mechanism on Unix and Win32 b) inheritance through a process tree.) They don't scale well I believe. Anyway, I'm not going to solve this and I doubt any of you will either.
 
Given that the spaces end up buried in %PATH%, %LIB%, and %INCLUDE%, where cmd, cl, link look and can cope, but where cm3 itself doesn't look at, the space problem is solved.
 
I install to
 \msdev\10 
 \msdev\15 
 \msdev\20 
 \msdev\40 
 \msdev\41 
 \msdev\42 
 \msdev\50 
 \msdev\60 
 \msdev\70 
 \msdev\71 
 \msdev\80 
 \mwerks\6 (metrowerks, not that I use it much)
 \mwerks\7 
 \mwerks\8 
 \dm or \dmars (digital mars, no versioning) 
 \cygwin (the default, no versioning)
 \mingwin (the default, no versioning) 
  etc.
 
I haven't yet settled on a grand unified file system layout for myself, though I do obsess over it, and sometimes give in to the defaults, can't fight every battle, not as often as I resetup machines.. and I haven't figured out what to do about source control and tools. Ideally, you checkin all your tools, but I'm not sure what that implies for copyright, esp. given a hosted source control system I don't control, and it'll bloat up my cheap hosted source control.. 
 
I do let the Platform SDK install to its default like \Program Files\Microsoft Platform SDK R2.
 
Bootstrapping current source from the 5.2.6 "min" binary distribution should work.
I tested this last night.
Should work from the larger "std", "core", etc. whatever there is.
I didn't try anything before 5.2.6.
 
There is a question as to which toolsets to support -- which toolset to build the distribution with.
The older you pick, the more reach you have to people using older toolsets.
However there seems to only be about three of us so I'm barking up a very hypothetical tree.. :(
 
As well a question as to what you can bootstrap with, which Modula-3 tools.
I imagine the more you go back, the more contorted things get, and there might be really nothing to gain.
Just pick the most recent good enough version and don't care about anything older? Look forward not backward?
 
I haven't seen many problems with %TEMP% and %TMP%. They do often somewhere get changed to short paths.
But I did recently have a problem with spaces in them.
 
Realize that "short paths" are NOT predictable.
And, btw, they aren't even necessarily "shorter" than the "long" path, though they do lack spaces, etc.
Try this:
mkdir \1.1.1
dir /x \1* 
 - Jay


Date: Fri, 30 Nov 2007 17:24:25 -0500From: rcoleburn at scires.comTo: jay.krell at cornell.edu; m3devel at elegosoft.comSubject: Re: [M3devel] some more notes on the win32 system

Jay:
 
Thanks for all your help.
 
Actually, the last time I tried to install cm3, I used the 5.26 tarballs and tried to build, but ran into some compile errors.  I'll try it again and report back the actual errors I get (if any).
 
As for Microsoft Visual Studio, yes I'm familiar with setting it up.
 
Are you saying that the cm3install program should no longer be used?  I've used this in the past.  The big issue I've run into is making sure to give old style 8.3 pathnames without spaces and to edit the cm3.cfg file to find all the libraries and stuff using paths without spaces.  I've also set some environment vars, in particular the TEMP and TMP vars, to use paths without spaces.
 
I will try to be very careful to document everything I do in great detail.  Perhaps we can use this to give out a better recipe to folks on how to get cm3 working on Windows.
 
Regards,
Randy>>> Jay <jay.krell at cornell.edu> 11/29/2007 8:48 PM >>>some more notes on the win32 system> setup your C++ compiler/linkerYou can/should "play dumb", skip that, and just run upgrade.See what errors you get.I tried to put in the right amount of up front sanity checking.What you need in particular arecl and link on the %PATH%.  See, cminstall would have you specify full paths, my configuration uses %PATH%.If using VS2005 (8) or newer, mt on the path.%LIB% is a semicolon delimited list of directories.That is a feature of the Microsoft linker.msvcrt.lib must be in one of them.Any 32 bit version of Visual C++ -- 2.0, 4.0,, 4.1, 4.2, 5.0, 6.0, 7.0, 7.1, 8.0 -- should work.I have tested all of them some and many required small changes in one particular spot, that actually is only used by "maintainers" (C:\dev2\cm3\m3-win\import-libs\src\make-lib-1.cmd).I use 8.0 the most lately.I haven't done much with 9.0. Another thing, fairly redundant: C:\dev2\cm3\m3-win>more vcredist.txtOn computers without Visual C++ 2005 or CLR 2.0 installed, download and run the setup for the Visual C++ runtime -- vcredist_x86.exe -- from either RTM (release to manufacturing):  http://www.microsoft.com/downloads/details.aspx?familyid=32BC1BEE-A3F9-4C13-9C99-220B62A191EE or Service Pack 1:  http://www.microsoft.com/downloads/details.aspx?FamilyID=200b2fd9-ae1a-4a14-984d-389c36f85647You can find those searching the web for vcredist, no real need to recort the URLs. That's about it. - Jay



Your smile counts. The more smiles you share, the more we donate. Join in! 
_________________________________________________________________
Your smile counts. The more smiles you share, the more we donate.  Join in.
www.windowslive.com/smile?ocid=TXT_TAGLM_Wave2_oprsmilewlhmtagline
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20071201/ac339d98/attachment-0001.html>