[M3devel] FW: [M3commit] CVS Update: cm3

[Jay]

truncated, around the cmd/bat stuff

From: jay.krell at cornell.eduTo: rcoleburn at scires.com; m3devel at elegosoft.comSubject: RE: [M3devel] [M3commit] CVS Update: cm3Date: Wed, 31 Dec 2008 18:34:24 +0000

 > you've made the CYGWIN implementation "appear"  > be the same as the native Windows implementation. > But they are not the same.  But they mostly are, from the front end's point of view.They are both little endian, x86, use the same jump_buf size (I grew it to match Cygwin's, which is a deoptimization of stack use on native NT386), the same type sizes and alignments..er..not sure about LONGINT.They might vary in newline and one uses the internal backend and one the external, however which backend they use is actually minor to the front end, though I think it affects if the front end "deals with" calling conventions, particularly left-to-right vs. right-to-left and struct returns.Object code produced by one can generally be linked with object code produced by the other.  SOLgnu and SOLsun are a better example of this, though they do go ahead and duplicate tons of stuff that if I had implemented them, I would have avoided.They are truly identical in every respect in the front end and back end.They only vary in the config file.This is wasteful, because, "by default", if I'm put together a comprehensive cross build system without being a little smarter, I end up building two identical m3cgs. My config files are willing to "probe across" SOLsun and SOLgnu though, so I need only one m3cg for the two of them.  Given that "NT386" can describe a combinatorial explosion of configurations, it makes some sense to keep it just one if possible. The compiler mostly doesn't care.  
 > "- BUILD_DIR does not necessarily equal HOST or TARGET,  > because of how I structured I386_CYGWIN to be a "configuration"  > where TARGET is still NT386." 
  > IMO, it would be wrong to change the meaning of things like "BUILD_DIR", "HOST", and "TARGET".   BUILD_DIR also does not equal HOST or TARGET when doing profiled builds, which admittedly I never have.Therefore, BUILD_DIR is arbitrary.I might be confusing something here though -- since I have never built a profiled build, I also haven't shipped one. It could be that "shipped BUILD_DIR" does equal TARGET, for profiled builds, in which case I did set a precedent. But the "override" code isn't using shipped files, so..I have to check.  > as long as it does not compromise the native Windows implementation Agreed and it basically doesn't.Show me where it does.The only thing I can think of is the jmpbuf size.  >  I don't want to have to install CYGWIN either in order to make > the native implementation work on Windows. Please don't complain about stuff that isn't true or without being more specific.I know of no dependency by the native implementation on Cygwin. In fact, installing Cygwin does tend to break the native implementation, depending on $PATH, because it has a link.exe that is a completely different program (ie: ln.exe).I tried experimenting with using cl to drive link.exe but couldn't quite get it to work, for stupid reasons related to response files, which surely is fixable by extending response file support in cm3... As it is, I usually delete \cygwin\bin\link.exe, or remove cygwin from $PATH.True, I don't ever uninstall Cygwin for testing, so the dependency could creep in by accident.   >  I also still prefer the CMINSTALL, CMD, or BAT files > for install as opposed to having to get Python or something else.  Just my 2 cents. Once built and installed, there is no dependency on cmd, bat, cminstall, or python.cminstall is pretty worthless imho, as long as you set PATH, INCLUDE, and LIB.That is also a competing workaround for paths with spaces.And allows moving around among different versions of Visual C++, which is good and bad.  Either you can have n installs of cm3, each configured tightly for one specific Visual C++,  or you can have 1 install of cm3, that is flexibly configured, that you "reconfigure" by altering the environment. I do the second. If you want to build the system, in a well automated way, with cmd and bat, you are welcome to write them.  Maybe the ones I left in the tree work, but i never use them any longer.  I use the Python all the time. Or you can manually cd around (as I suspect Tony does).Personally I find cmd/bat among the worst programming languages ever and would rather not write it.jscript via cscript.exe would be a good alternative, it is always there at least as of Windows 2000 or perhaps with IE installed on older versions, but then you have to duplicate work across Unix and Windows.That is, for Windows-only no-cmd, no-install command line automation, JScript and VBScript are good choices, but Windows-only rules them out. The install is worth it.Python is a very decent programming language that is very portable across "all" systems.Perl would be the next best choice, though..I just don't like much.sh/bash requires an install on Windows, so its built-inness on Posix I claim isn't a conclusive win.I strongly encourage you to try out Python. Another avenue is to merge the sh/cmd/python into cm3 itself.It shouldn't be all that hard. Modula-3 still needs a C linker.And there is C code that I didn't put in -- hand.c and dtoa.c.If someone writes a linker in Modula-3, or gets the .obj loader working, I'll be more open to eliminating C. But using C is much less error prone and much more portable, in some parts of the system. You may label C as "evil", but the other "evil" I am battling is tedious error prone "header cloning".You pretty much must chose one.The header cloning can be reduced, and its error proned-ness and difficulty various per system, depending on how gnarled up the headers are with ifdefs, compatibility hacks, processor-specificty, "cleansing" (where the installed headers are processor specific, deriving from #ifdef'ed or somesuch other files, but now I argue both sides, #ifdef is hard to read, but removing them removes information unless you track further back), etc. For example the OpenBSD headers are much more readable. I suspect NetBSD are too but haven't looked yet. The Linux headers contain a lot of #ifdef and they are also processor-specific I think -- you know, my /usr/include/errno.h on one system I think didn't show that x86 and SPARC use different values.   - Jay

Date: Wed, 31 Dec 2008 10:28:37 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] [M3commit] CVS Update: cm3
Jay:
 
Please explain what you mean by: 
 
"- BUILD_DIR does not necessarily equal HOST or TARGET,because of how I structured I386_CYGWIN to be a "configuration"where TARGET is still NT386."
 
IMO, it would be wrong to change the meaning of things like "BUILD_DIR", "HOST", and "TARGET".  Indeed, I have stuff that depends on the meaning of these things.  Your statement seems to imply that "under the covers" you've made the CYGWIN implementation "appear" to be the same as the native Windows implementation.  But they are not the same.
 
On another note, All this CYGWIN stuff may be a nice way for die-hard Unix fans to run Modula-3 on Windows, and I have no objection to providing it, as long as it does not compromise the native Windows implementation.  My main concern is the native implementation of Modula-3 on Windows.  My preference would be to keep the NT386 implementation's dependencies on other stuff to a bare minimum, i.e., don't introduce anything that would require someone to have to acquire something besides what comes in the standard Windows OS in order to make Modula-3 run.  As it is now, we already have to get a C compiler and linker.  Fortunately, Microsoft has made the Visual Studio Express editions a free download, so this is not too bad.  I don't want to have to install CYGWIN either in order to make the native implementation work on Windows.  I also still prefer the CMINSTALL, CMD, or BAT files for install as opposed to having to get Python or something else.  Just my 2 cents.
 
Finally, I would go a step further and suggest that the Modula-3 implementation on every platform should strive to require minimal dependencies on anything not provided standard with that platform's operating system.
 
Call me an idealist, but it just galls me that I have to have a C compiler/linker to build Modula-3.  Modula-3 is a systems programming language.  It should stand on its own.  From a purely economical viewpoint, why should I have to buy something I don't want (C language development environment) in order to have the privilege of using what I do want (Modula-3 language development environment).
 
Regards,
Randy>>> Jay Krell <jkrell at elego.de> 12/31/2008 11:52 AM >>>CVSROOT:/usr/cvsChanges by:jkrell at birch.08/12/31 11:52:08Modified files:cm3/m3-comm/netobj/src/: netobj-ov.tmpl cm3/m3-comm/sharedobj/src/: sharedobj-ov.tmpl cm3/m3-libs/libm3/src/bundleintf/: bundle-ov.tmpl cm3/m3-ui/zeus/src/: m3zume-ov.tmpl cm3/m3-ui/juno-2/juno-app/src/: m3makefile Log message:Partly kinda sorta fix some cross build scenarios, withoutaffecting native builds.It's a larger more general problem though.- BUILD_DIR does not necessarily equal HOST or TARGET,because of how I structured I386_CYGWIN to be a "configuration"where TARGET is still NT386.- a cross build can run the shipped binary anyway,and probably should (I didn't have the unshipped binaries around)- There should probably be automation to ensure all the tools are build.ie: do-cm3-tools or do-cm3-crosstools. ie: build just the needed packages,for the sniffed native platform.Cross builds have other problems.I keep hitting the following annoyances:ignoring foo/bar override when foo\bar already overriddenoverride paths should either be canonicalized to one slash typeor at least when there is a duplicate, canonicalize then and onlycomplain if canonicals varyThis is due to mixing I386_NT and I386_CYGWIN.Similarly the problem demonstrated regarding m3unix.h in Uwaitpid.quake.Perhaps the change I made to allow forward slashes on Win32 was not good, esp. due toits apparent inadequacy.The "lib" directory, specifically \cm3\lib\hand.obj is target..er, configuration dependentthe gcc hand.obj cannot be directly linked by Visual C++, for reasons to do with libgcclib should probably have "target" or "build_dir" under itand/or hand.obj specifically should be merged into m3core.libThe mentor quake code generally fails in cross environments, probably due to slashes.host=NT386 (GNU?), target=LINUXLIBC6 m3zume is access violatingI'm also highly suspicious of all this "override" stuff.It clearly causes too much duplication and distribution of information.I shouldn't have to know the directory structure of my dependencies,and even if I do, I should be able to share that knowledge with their manyother dependents. The "scripts" directory also figures this sort of stuff out automatically..Being able to have multiple package stores is well and good.I'm not sure they need to ever be used in an "unshipped" form, but instead justuse alternate roots and create new empty roots as needed. ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20081231/85f6b06a/attachment-0002.html>