<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>Final answer?<BR>
<BR>
I played around with this but just can't accept platforms/build_dirs like:<BR>
ntx86msmsmscm3msn<BR> ntx86gccgcccm3cgmsn<BR> ntx86gccgcccm3cgxn<BR> ntx86-gggggmn<BR> ntx86-ggixn<BR> ntx86_mmmimm<BR>
<BR>Ok, I have one more name here, and then a bit of a change, or<BR> a stronger statement of something I had already said.<BR>
<BR>NT386MINGNU<BR>
<BR>Ok, I think we (me!) are confusing host and target, MOSTLY.<BR>
<BR>And cm3 might not have them quite divided appropriately.<BR>
<BR>What is a "host"? What is a "target"?<BR>
<BR>MinGWin and Visual C++ output similar results, targeting<BR>the same runtime (usually), threading library, windowing library.<BR>There is a chance for exception handling to diverge however.<BR>Well, speaking of Visual C++ the C/C++ compiler and MinGWin<BR>the gcc environment, yes, very different, not interoperable.<BR>MinGWin uses what gcc calls "sjlj" -- setjmp/longjmp exceptions.<BR>Very inefficient. But heck, gcc doesn't support __try/__except/__finally,<BR>only C++ exceptions, and interop of C++ is often not great,<BR>what with name mangling and all.<BR>
<BR>NT386GNU's OUTPUT uses a different runtime, unless you<BR> trim dependencies, possibly a different threading library,<BR> possibly a different windowing library. All this probably<BR> configurable. Again exception handling is a sore point in<BR> that it is the primary C runtime dependency of Modula-3.<BR>
If you use Cygwin but say -mno-cygwin, that means<BR>
you are targeting NT386. (and don't use pthreads or X Windows;<BR>
behavior of exceptions/setjmp/longjmp TBD -- really, need<BR>
to not use the -mno-cygwin headers in that case; I'll check).<BR>
<BR>Perhaps m3core.dll should export m3_setjmp/m3_longjmp..<BR>
<BR>Either one can do a cross build to the other.<BR>Two cm3.exes, two sets of outputs, that either can produce.<BR>
<BR>NT386 can use gcc or the integrated backend.<BR> And the gcc it uses can be MinGWin or Cygwin. (theoretically and probably soon reality)<BR>
<BR>
NT386GNU can use either as well! (also currently theory, but a real possibility)<BR> It isn't GNU tools, it is GNU runtime.<BR>
<BR>One small area with cm3 might fall down just slightly is that of<BR> cross builds where host and target have different naming conventions.<BR> -lfoo vs. foo.lib, foo.o vs. foo.obj are an aspect of the host and<BR> I vaguely recall that cm3 ties naming convention to ostype.<BR> The appending of .exe is a target characteristics, but the others are not really.<BR> Naming convention is really a host thing and not a target thing.<BR>
<BR>The config files are a mix of host and target information, mostly actually host,<BR> except for the one line that says TARGET. Most of the target variation is in cm3,<BR> which always can do any, and cm3cg (which might be nice to be similar, but that's<BR> another matter and not likely to ever change, except when AMD64 is the last<BR> architecture standing. :) )<BR>
<BR>If Windows had "rpath", then SL would be split between HOST_SL and TARGET_SL.<BR>As it stands, SL is HOST_SL.<BR>
<BR>Consider as well the various versions of Visual C++.<BR>They output mostly the same, very interoperable.<BR>
<BR>Consider optimization switches. Host or target?<BR>Consider version of gcc or Visual C++? Host or target?<BR>Well, inevitably, the host has an affect on the target.<BR> If not the for the host, the target would not even exist.<BR> Bugs in the host produce bugs in the target.<BR> etc.<BR>
<BR>(And realize that Cygwin runs on top of an OS built with<BR>a Microsoft compiler, so really there is interop, but sometimes through a layer.)<BR>
<BR>
So there's a risk of saying there is six+ combinations.<BR>
(host cygwin, host mingwin, host native) x (target nt386, target nt386gnu) <BR>
<BR>
But generally the host is assumed not a factor.<BR>
<BR>
I guess "LIBC" could be seperated into several options...<BR>
You could actually have code that needs one runtime or another, and they could<BR>
link together, depending on what they do..<BR>
<BR>
This is something I don't know if cm3 handles, or anything I have seen.<BR>
I should be able to build a static .lib, that includes some C code, that imbues its<BR>
clients with build time dependencies. Well, I guess #pragma comment(linker) is this.<BR><BR>
So the next tasks are roughly:<BR>
Merge my NT386 and NT386GNU files.<BR>
Switching on a variable such as backend mode.<BR>
<BR>
Introduce a "new" (old) NT386GNU file, perhaps more like what was already there.<BR>
<BR>
Change NT386GNU back to Posix.<BR>
<BR>
Build NT386GNU.<BR>
<BR>
oh, one more point...while these are two targets from cm3's point of view, they are PROBABLY the same target to cm3cg<BR>
and so only one is needed. I have to check if configure differentiates between i686-pc-cygwin and i686-pc-mingwin...<BR>
but I guess it should...<BR>
It might actually be profitable to have two bloated cm3cg.exe's.<BR>
And they should ship to \cm3\pkg\m3cc\target\host or host\target and cm3 should know which to run.<BR>
Blech..four of them when one would suffice?<BR>
The detail being mainly what the paths to .libs look like, unfortunate.<BR>
Possibly cm3 can bridge this gap using that "broken" feature that symlinks libs into the target directory,<BR>
using NTFS hard links, if installroot and root are on the same volume... (or symlinks on Vista).<BR>
Or maybe convert the paths as appropriate, hacky, but saves an extra cm3cg.exe which is good to avoid.<BR>
<BR>
(all the more reason to lump all targets into one file, so that the host x target matrix collapses to just one axis, host; and<BR>
then you can write stuff in Perl/Python/Java/C# to collapse that to just one, except for the underlying runtime/interpreter...)<BR>
<BR>
Oh, cm3cg isn't the issue. It is always sitting in the correct directory and reads one file and writes one file, no slashes.<BR>
The issue is gcc as the linker. Again, this is a host issue..and cm3 or the config file definitely should do the translation.<BR>
<BR>
- Jay<BR><BR>
<BLOCKQUOTE>
<HR id=EC_stopSpelling>
From: jayk123@hotmail.com<BR>To: m3devel@elegosoft.com<BR>Date: Mon, 21 Jan 2008 23:01:44 +0000<BR>Subject: [M3devel] platform/build_dir is a big tuple?<BR></BLOCKQUOTE><br /><hr />Need to know the score, the latest news, or you need your HotmailŪ-get your "fix". <a href='http://www.msnmobilefix.com/Default.aspx' target='_new'>Check it out.</a></body>
</html>