<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>
It looks like at least cm3 is "always" target-independent.<BR>
Whatever target is defined to in cm3.cfg, if it is one of the built in known ones, cm3 will generate code for. Except maybe NT386, though it need not be -- cm3 could have both the .obj and "gcc tree" writing backends both linked into it and dynamically chose between them. Maybe it already does.<BR>
cm3 operates at a fairly high level when using gcc, and the target specific stuff is just some data about the name of setjmp, the sizeof jmp_buf, etc..<BR><BR>The "only" "problem" is then m3cg/as/ld/link.<BR>m3cg could be moved to $CM3_INSTALL/pkg/x/HOST/TARGET.<BR>
<BR>
cm3, along with everything else, could be $CM3_INSTALL/pkg/x/HOST<BR>
leaving $CM3_INSTALL/bin/cm3 that is sh and $CM3_INSTALL/bin/cm3.py or cm3.cmd that calls out to cm3.<BR>
<BR>
"Fixing" as/ld, well, I don't suppose they tend to be target neutral do they? You'd have to import them like gcc and build them n times. Gaining a much slower build, much larger tree.<BR>
<BR>
I suppose anyone could do this themselves, and change cm3.cfg appropriately. Doing things "officially" this way for one "big" distribution, probably folks would not go for.<BR>
<BR>
- Jay<BR><BR>
<BR>
<HR>
<BR>
From: jayk123@hotmail.com<BR>To: m3devel@elegosoft.com<BR>Subject: "crazy cross"<BR>Date: Sat, 5 Jan 2008 01:22:13 +0000<BR><BR>
<META content="Microsoft SafeHTML" name=Generator>
<STYLE>
.ExternalClass .EC_hmmessage P
{padding:0px;}
.ExternalClass EC_body.hmmessage
{font-size:10pt;font-family:Tahoma;}
</STYLE>
You've all heard of "Canadian cross"?<BR><BR>It is cross-building a cross-compiler.<BR>I'm sitting in Windows. I'm going to build a compiler that is going to run on Linux that is going to target Solaris.<BR>For one example.<BR><BR>You've all seen that Apple has switches like so:<BR><BR>gcc -arch i386 ppc ppc64 x86_64 hello.c<BR>and poof out comes a binary that runs natively on four architectures<BR><BR>I don't like the "inconvenience" of non cross systems and having to have all the machines/OSes just to build the binaries.<BR>I realize that you hit the wall if you actually want to test the results. So cross building only gets so much.<BR>Of course I also don't want to multiply out build times for tools...<BR><BR>Ok, well what is the possibility of:<BR><BR>cm3 -target NT386<BR>cm3 -target NT386 -target PPC_DARWIN<BR><BR>? In my crazy imagination, you have:<BR><BR> \cm3\bin\cm3.cmd <BR> %~dp0..\libexec\%processor_architecture%\%TARGET%\cm3.exe %*<BR> <BR> \cm3\bin\cm3 <BR> #!/bin/sh <BR> dirname(dirname($0))/libexec/`uname whatever`/$TARGET/cm3 $@<BR><BR>Thus it becomes POSSIBLE to have an n x m matrix, host x target, and be able to build<BR>"anything" from one environment.<BR><BR>Actually the targets could all be merged into one .exe or be .dll/.sos.<BR>Except the code isn't setup for that.<BR><BR>Interesting?<BR><BR>I guess the hard part is the C code and linking?<BR>The Modula-3 stuff is already setup to do most of this?<BR> (partly by virtue of all that header rewriting that I labeled sleazy)<BR><BR> - Jay<BR><BR><BR>
<HR>
<BR>
Share life as it happens with the new Windows Live. <A href="http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008" target=_blank>Start sharing!</A> <BR><br /><hr />Share life as it happens with the new Windows Live. <a href='http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008' target='_new'>Start sharing!</a></body>
</html>