[M3devel] platform/build_dir is a big tuple?

[Jay]

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


From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Mon, 21 Jan 2008 23:01:44 +0000Subject: [M3devel] platform/build_dir is a big tuple?
_________________________________________________________________
Need to know the score, the latest news, or you need your Hotmail®-get your "fix".
http://www.msnmobilefix.com/Default.aspx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080122/222bcf90/attachment-0002.html>