<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-15">
<META content="MSHTML 6.00.6000.16788" name=GENERATOR></HEAD>
<BODY style="MARGIN: 4px 4px 1px">
<DIV>Jay:</DIV>
<DIV> </DIV>
<DIV>Please explain what you mean by: </DIV>
<DIV> </DIV>
<DIV>"- BUILD_DIR does not necessarily equal HOST or TARGET,<BR>because of how I structured I386_CYGWIN to be a "configuration"<BR>where TARGET is still NT386."</DIV>
<DIV> </DIV>
<DIV>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.</DIV>
<DIV> </DIV>
<DIV>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.</DIV>
<DIV> </DIV>
<DIV>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.</DIV>
<DIV> </DIV>
<DIV>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).</DIV>
<DIV> </DIV>
<DIV>Regards,</DIV>
<DIV>Randy<BR><BR>>>> Jay Krell <jkrell@elego.de> 12/31/2008 11:52 AM >>><BR>CVSROOT:/usr/cvs<BR>Changes by:jkrell@birch.08/12/31 11:52:08<BR><BR>Modified files:<BR>cm3/m3-comm/netobj/src/: netobj-ov.tmpl <BR>cm3/m3-comm/sharedobj/src/: sharedobj-ov.tmpl <BR>cm3/m3-libs/libm3/src/bundleintf/: bundle-ov.tmpl <BR>cm3/m3-ui/zeus/src/: m3zume-ov.tmpl <BR>cm3/m3-ui/juno-2/juno-app/src/: m3makefile <BR><BR>Log message:<BR>Partly kinda sorta fix some cross build scenarios, without<BR>affecting native builds.<BR><BR>It's a larger more general problem though.<BR><BR>- BUILD_DIR does not necessarily equal HOST or TARGET,<BR>because of how I structured I386_CYGWIN to be a "configuration"<BR>where TARGET is still NT386.<BR><BR>- a cross build can run the shipped binary anyway,<BR>and probably should (I didn't have the unshipped binaries around)<BR><BR>- There should probably be automation to ensure all the tools are build.<BR>ie: do-cm3-tools or do-cm3-crosstools. ie: build just the needed packages,<BR>for the sniffed native platform.<BR><BR>Cross builds have other problems.<BR><BR>I keep hitting the following annoyances:<BR><BR>ignoring foo/bar override when foo\bar already overridden<BR>override paths should either be canonicalized to one slash type<BR>or at least when there is a duplicate, canonicalize then and only<BR>complain if canonicals vary<BR>This is due to mixing I386_NT and I386_CYGWIN.<BR>Similarly the problem demonstrated regarding m3unix.h in Uwaitpid.quake.<BR><BR>Perhaps the change I made to allow forward slashes on Win32 was not good, esp. due to<BR>its apparent inadequacy.<BR><BR>The "lib" directory, specifically \cm3\lib\hand.obj is target..er, configuration dependent<BR>the gcc hand.obj cannot be directly linked by Visual C++, for reasons to do with libgcc<BR><BR>lib should probably have "target" or "build_dir" under it<BR><BR>and/or hand.obj specifically should be merged into m3core.lib<BR><BR>The mentor quake code generally fails in cross environments, probably due to slashes.<BR><BR>host=NT386 (GNU?), target=LINUXLIBC6 m3zume is access violating<BR><BR>I'm also highly suspicious of all this "override" stuff.<BR>It clearly causes too much duplication and distribution of information.<BR>I shouldn't have to know the directory structure of my dependencies,<BR>and even if I do, I should be able to share that knowledge with their many<BR>other dependents. The "scripts" directory also figures this sort of stuff out automatically..<BR>Being able to have multiple package stores is well and good.<BR>I'm not sure they need to ever be used in an "unshipped" form, but instead just<BR>use alternate roots and create new empty roots as needed. ?<BR><BR><BR></DIV></BODY></HTML>