[M3devel] [M3commit] CVS Update: cm3

[Randy Coleburn]

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/cvs
Changes by:jkrell at birch.08/12/31 11:52:08

Modified 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, without
affecting 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 overridden
override paths should either be canonicalized to one slash type
or at least when there is a duplicate, canonicalize then and only
complain if canonicals vary
This 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 to
its apparent inadequacy.

The "lib" directory, specifically \cm3\lib\hand.obj is target..er, configuration dependent
the gcc hand.obj cannot be directly linked by Visual C++, for reasons to do with libgcc

lib should probably have "target" or "build_dir" under it

and/or hand.obj specifically should be merged into m3core.lib

The mentor quake code generally fails in cross environments, probably due to slashes.

host=NT386 (GNU?), target=LINUXLIBC6 m3zume is access violating

I'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 many
other 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 just
use 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/88fe30fa/attachment-0002.html>