
<html>

<head>

<style>

.hmmessage P

{

margin:0px;

padding:0px

}

body.hmmessage

{

FONT-SIZE: 10pt;

FONT-FAMILY:Tahoma

}

</style>

</head>

<body class='hmmessage'>I know, I've heard it many times from smart people, but sorry I can't resist. I will strive for a balance.<BR>

 <BR>

In particular I'm thinking<BR>

 <BR>

NT386<BR>

  sets a few globals as described<BR>

  include NT386.common<BR><BR>NT386GNU<BR>

  sets a few globals as described<BR>

  include NT386.common<BR><BR>NT386MINGNU<BR>

  sets a few globals as described<BR>

  include NT386.common<BR><BR>

NT386.common will not be the simplest.<BR>

 <BR>

CM3 might know about a few more of these globals than it already does.<BR>

 <BR>

Under the covers, there is already lots and lots and lots of complexity and always will be (look at the stuff I debugged, which I admit was half stupid since PM3 had half the diffs -- I didn't find their config file to see about the double alignment though, so I was stuck debugging that afaik).<BR>

 <BR>

 - Jay<BR><BR>


<HR id=stopSpelling>

<BR>

> Date: Tue, 22 Jan 2008 14:29:22 +0100<BR>> From: wagner@elegosoft.com<BR>> To: m3devel@elegosoft.com<BR>> Subject: Re: [M3devel] platform/build_dir is a big tuple?<BR>> <BR>> All this may be useful during development, but it is not really<BR>> useful for a software distribution to our users, I think.<BR>> <BR>> Nobody will understand it :-( We need to keep things more simple.<BR>> <BR>> We don't need to support everything out of the box. Instead, we should<BR>> offer some sensible default combinations of everyhing you describe.<BR>> <BR>> First of all: we don't distribute cross compilers (at least until now).<BR>> This is a special topic reserved for adding new platforms.<BR>> <BR>> Runtime and compilers used do not necessarily need to be distinguished<BR>> by target or build dir, in many cases different cm3.cfg may suffice.<BR>> <BR>> Until now, threading models are also no choice that needs to be<BR>> visible at this level. There's one default model for every target,<BR>> and the user can change it by recompiling.<BR>> <BR>> And if we should really agree that changing the target naming scheme<BR>> is a good idea, we should<BR>> <BR>> o use a systematic one with not more than 4 elements (better still,<BR>> 3 (e.g. <arch>-<os>-<variant>))<BR>> o don't use cryptic abbreviations that will confuse most people<BR>> <BR>> Just my 2 cents,<BR>> <BR>> Olaf<BR>> <BR>> Quoting Jay <jayk123@hotmail.com>:<BR>> > I'm still torn over that any NT386 target could have a choice of <BR>> > three threading models (win32, pthread, vtalarm), two windowing <BR>> > libraries (ms, x), two (three) compilers (ms, mingwin, cygwin), two <BR>> > (three) linkers (ms, mingwn, cygwin), various runtimes (msvc various <BR>> > versions, cygwin, mingwin (discouraged)) etc.<BR>> ><BR>> > Appending a short string of unreadable bits to BUILD_DIR is very <BR>> > temptingin order to easily generate and test the combinatorial <BR>> > possibilities.<BR>> ><BR>> > backend: 0 integrated, 1 gcc already a setting (with four values)<BR>> ><BR>> > ccompiler/linker: 0 ms, 1 gcc (these could be split, and could <BR>> > allocate more bits...) maybe 00 ms, 01 cygwin, 10 ming maybe define <BR>> > enum up front that allows for watcom, metrowerks, digitalmars, llvm <BR>> > etc.<BR>> > maybe use a decimal digit for all these, and 0 is reserved, maybe.<BR>> ><BR>> > threading: 0 win32, 1 pthreads drop vtalarm, or use two bits?<BR>> ><BR>> > windowing: 0 ms, 1 x<BR>> ><BR>> > cruntime: 0 ms, 1 cyg There is also a ming runtime, discouraged <BR>> > There also really N ms runtimes, ming offers several: msvcrt.dll, <BR>> > msvcr70.dll, msvcr71.dll, msvcr80.dll, msvcr90.dll... but jmpbuf <BR>> > presumbly doesn't change again could allocate multiple bits..<BR>> ><BR>> > cruntime I guess determines oSTYPE Win32 or Posix, thoughit loses <BR>> > its meaning mostly, and X vs. not-X is usually decide the same...<BR>> ><BR>> > The three most common combinations: 00000 -- NT386 11111 -- <BR>> > NT386GNU 11000 -- NT386MINGNU<BR>> ><BR>> > but several others would work 11101 -- cygwin with native windowing <BR>> > 11011 -- cygwin with native threads 11001 -- cygwin with native <BR>> > threads and native windowing<BR>> > BUILD_DIR would be NT386-$(config)as a special case perhaps, the <BR>> > three commoncases could be translated to the above strings.<BR>> ><BR>> > But the underlying implementation would be a few bools/enums,and <BR>> > iterating through them would be easy, while special casingand <BR>> > skipping deemed invalid combinations, like ms runtime and <BR>> > pthreads,and possibly ms runtime and x windows.<BR>> > Really, it might surprise folks, but really, basically every single <BR>> > combination works.<BR>> > Compilers are very independent of headers and libs and headers and <BR>> > libs are very independent of compilers, aside from a few language <BR>> > extensions like __stdcall. You can generally mix runtimes in the <BR>> > same process, just as you can mix them on the same machine, you just <BR>> > need to be careful about what you pass to what. If you call fopen, <BR>> > be sure pass the result back to the matching fclose, malloc/free, <BR>> > etc. Startup code, to the extent that it matters, might be a <BR>> > problem, but really, just avoid C++ globals with <BR>> > constructors/destructors anyway, they are always a problem. Modula-3 <BR>> > has its own startup code, and if you were to write "main" in C and <BR>> > link in Modula-3 static .libs, that probably doesn't work...might <BR>> > actually be better to play into whatever the platform's C++ <BR>> > constructor story is, as problematic as they (probably always?) are <BR>> > -- i.e. unpredictable/hard-to-control ordering.<BR>> ><BR>> > (bad editing...and maybe use hex for compression..)<BR>> ><BR>> > Bringing back cminstall is almost interesting, to promptthe user, or <BR>> > probe their system, though Quake/cm3 can probe at runtime.if os == <BR>> > windows_nt system_cc | findstr version | findstr gcc else <BR>> > system_cc | findstr visual c++else system_cc | grep version | grep <BR>> > gcc else system_cc | grep visual c++end<BR>> ><BR>> > inefficient.<BR>> ><BR>> > anyway, I'll merge current NT386GNU into NT386 and make it chosehow <BR>> > to compile/link which are the main variables today.<BR>> > and then decide about cygwin, but probably do like the above, <BR>> > sinceit'll totally share code with NT386 except the naming <BR>> > conventionsand the removal of the -mno-cygwin switch..<BR>> ><BR>> > I know this seems overly complicated, but it should be <BR>> > exposableeasily enough to users by hiding the choices, presenting <BR>> > three basic ones,and still allow all the obvious and perhaps useful <BR>> > knobs, and iterating throughthe combinations, without creating a <BR>> > combinatorial explosion of source filesor Modula-3 or Quake code.<BR>> > ...Jay<BR>> ><BR>> ><BR>> > From: jayk123@hotmail.comTo: m3devel@elegosoft.comDate: Tue, 22 Jan <BR>> > 2008 10:48:56 +0000Subject: Re: [M3devel] platform/build_dir is a <BR>> > big tuple?<BR>> ><BR>> ><BR>> > Final answer? I played around with this but just can't accept <BR>> > platforms/build_dirs like: ntx86msmsmscm3msn ntx86gccgcccm3cgmsn <BR>> > ntx86gccgcccm3cgxn ntx86-gggggmn ntx86-ggixn ntx86_mmmimmOk, I <BR>> > have one more name here, and then a bit of a change, or a stronger <BR>> > statement of something I had already said.NT386MINGNUOk, I think we <BR>> > (me!) are confusing host and target, MOSTLY.And cm3 might not have <BR>> > them quite divided appropriately.What is a "host"? What is a <BR>> > "target"?MinGWin and Visual C++ output similar results, targetingthe <BR>> > same runtime (usually), threading library, windowing library.There <BR>> > is a chance for exception handling to diverge however.Well, speaking <BR>> > of Visual C++ the C/C++ compiler and MinGWinthe gcc environment, <BR>> > yes, very different, not interoperable.MinGWin uses what gcc calls <BR>> > "sjlj" -- setjmp/longjmp exceptions.Very inefficient. But heck, gcc <BR>> > doesn't support __try/__except/__finally,only C++ exceptions, and <BR>> > interop of C++ is often not great,what with name mangling and <BR>> > all.NT386GNU's OUTPUT uses a different runtime, unless you trim <BR>> > dependencies, possibly a different threading library, possibly a <BR>> > different windowing library. All this probably configurable. Again <BR>> > exception handling is a sore point in that it is the primary C <BR>> > runtime dependency of Modula-3. If you use Cygwin but say <BR>> > -mno-cygwin, that means you are targeting NT386. (and don't use <BR>> > pthreads or X Windows; behavior of exceptions/setjmp/longjmp TBD -- <BR>> > really, need to not use the -mno-cygwin headers in that case; I'll <BR>> > check).Perhaps m3core.dll should export <BR>> > m3_setjmp/m3_longjmp..Either one can do a cross build to the <BR>> > other.Two cm3.exes, two sets of outputs, that either can <BR>> > produce.NT386 can use gcc or the integrated backend. And the gcc <BR>> > it uses can be MinGWin or Cygwin. (theoretically and probably soon <BR>> > reality) NT386GNU can use either as well! (also currently theory, <BR>> > but a real possibility) It isn't GNU tools, it is GNU runtime.One <BR>> > small area with cm3 might fall down just slightly is that of <BR>> > cross builds where host and target have different naming <BR>> > conventions. -lfoo vs. foo.lib, foo.o vs. foo.obj are an aspect <BR>> > of the host and I vaguely recall that cm3 ties naming convention <BR>> > to ostype. The appending of .exe is a target characteristics, but <BR>> > the others are not really. Naming convention is really a host <BR>> > thing and not a target thing.The config files are a mix of host and <BR>> > target information, mostly actually host, except for the one line <BR>> > that says TARGET. Most of the target variation is in cm3, which <BR>> > always can do any, and cm3cg (which might be nice to be similar, <BR>> > but that's another matter and not likely to ever change, except <BR>> > when AMD64 is the last architecture standing. :) )If Windows had <BR>> > "rpath", then SL would be split between HOST_SL and TARGET_SL.As it <BR>> > stands, SL is HOST_SL.Consider as well the various versions of <BR>> > Visual C++.They output mostly the same, very interoperable.Consider <BR>> > optimization switches. Host or target?Consider version of gcc or <BR>> > Visual C++? Host or target?Well, inevitably, the host has an affect <BR>> > on the target. If not the for the host, the target would not even <BR>> > exist. Bugs in the host produce bugs in the target. etc.(And <BR>> > realize that Cygwin runs on top of an OS built witha Microsoft <BR>> > compiler, so really there is interop, but sometimes through a <BR>> > layer.) So there's a risk of saying there is six+ <BR>> > combinations.(host cygwin, host mingwin, host native) x (target <BR>> > nt386, target nt386gnu) But generally the host is assumed not a <BR>> > factor. I guess "LIBC" could be seperated into several options...You <BR>> > could actually have code that needs one runtime or another, and <BR>> > they couldlink together, depending on what they do.. This is <BR>> > something I don't know if cm3 handles, or anything I have seen. I <BR>> > should be able to build a static .lib, that includes some C code, <BR>> > that imbues its clients with build time dependencies. Well, I <BR>> > guess #pragma comment(linker) is this.So the next tasks are <BR>> > roughly: Merge my NT386 and NT386GNU files. Switching on a <BR>> > variable such as backend mode. Introduce a "new" (old) NT386GNU <BR>> > file, perhaps more like what was already there. Change NT386GNU <BR>> > back to Posix. Build NT386GNU. oh, one more point...while these <BR>> > are two targets from cm3's point of view, they are PROBABLY the <BR>> > same target to cm3cgand so only one is needed. I have to check if <BR>> > configure differentiates between i686-pc-cygwin and <BR>> > i686-pc-mingwin...but I guess it should...It might actually be <BR>> > profitable to have two bloated cm3cg.exe's.And they should ship to <BR>> > \cm3\pkg\m3cc\target\host or host\target and cm3 should know which <BR>> > to run.Blech..four of them when one would suffice?The detail being <BR>> > mainly what the paths to .libs look like, unfortunate.Possibly cm3 <BR>> > can bridge this gap using that "broken" feature that symlinks libs <BR>> > into the target directory,using NTFS hard links, if installroot and <BR>> > root are on the same volume... (or symlinks on Vista).Or maybe <BR>> > convert the paths as appropriate, hacky, but saves an extra <BR>> > cm3cg.exe which is good to avoid. (all the more reason to lump all <BR>> > targets into one file, so that the host x target matrix collapses <BR>> > to just one axis, host; andthen you can write stuff in <BR>> > Perl/Python/Java/C# to collapse that to just one, except for the <BR>> > underlying runtime/interpreter...) Oh, cm3cg isn't the issue. It is <BR>> > always sitting in the correct directory and reads one file and <BR>> > writes one file, no slashes.The issue is gcc as the linker. Again, <BR>> > this is a host issue..and cm3 or the config file definitely should <BR>> > do the translation. - Jay<BR>> ><BR>> ><BR>> > From: jayk123@hotmail.comTo: m3devel@elegosoft.comDate: Mon, 21 Jan <BR>> > 2008 23:01:44 +0000Subject: [M3devel] platform/build_dir is a big <BR>> > tuple?<BR>> ><BR>> > Need to know the score, the latest news, or you need your <BR>> > Hotmail�-get your "fix". Check it out.<BR>> > _________________________________________________________________<BR>> > Climb to the top of the charts! Play the word scramble challenge <BR>> > with star power.<BR>> > http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan<BR>> <BR>> <BR>> <BR>> -- <BR>> Olaf Wagner -- elego Software Solutions GmbH<BR>> Gustav-Meyer-Allee 25 / Geb�ude 12, 13355 Berlin, Germany<BR>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95<BR>> http://www.elegosoft.com | Gesch�ftsf�hrer: Olaf Wagner | Sitz: Berlin<BR>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194<BR>> <BR><BR><br /><hr />Climb to the top of the charts!�Play the word scramble challenge with star power. <a href='http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan' target='_new'>Play now!</a></body>

</html>