
<html>

<head>

<style>

.hmmessage P

{

margin:0px;

padding:0px

}

body.hmmessage

{

FONT-SIZE: 10pt;

FONT-FAMILY:Tahoma

}

</style>

</head>

<body class='hmmessage'>Two of the types are dead and the calling convention doesn't matter.<BR>

If the function has any parameters, a LOOPHOLE is needed, if it has no pararemeters, as the types are declared, the calling convention has no affect. So fixing the warnings are trivial and will be done momentarily.<BR>

 <BR>

 <BR>

 - Jay<BR><BR>

<BLOCKQUOTE>

<HR id=EC_stopSpelling>

From: jayk123@hotmail.com<BR>To: hosking@cs.purdue.edu; wagner@elegosoft.com<BR>CC: m3devel@elegosoft.com<BR>Subject: RE: [M3devel] platform/build_dir is a big tuple?<BR>Date: Wed, 23 Jan 2008 02:25:39 +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>


<DIV style="TEXT-ALIGN: left">> Precisely why I don't like many of the recent changes. I don't want <BR>> to build Windows interfaces and gorp for a non-Windows platform. <BR></DIV><BR>It is *just* types. (I didn't read the code entirely, but it appears so).<BR>Other than the three or so types marked WINAPI, which I could see about moving/removing,<BR>*types* work fine across architectures.<BR>You could produce and consume these types in pure Modula-3 on any platform.<BR>That kernel32.dll happens to traffic in them is just coincidence.<BR>Except maybe those function pointer types with WINAPI.<BR><BR>What's wrong with that?<BR><BR>As long as I can fix the warnings I think these should say.<BR>Not that there aren't lots of warnings in the build already, but I don't like having any.<BR><BR> - Jay<BR><BR><BR>

<HR id=EC_stopSpelling>

> From: hosking@cs.purdue.edu<BR>> Date: Tue, 22 Jan 2008 12:54:04 -0500<BR>> To: wagner@elegosoft.com<BR>> CC: m3devel@elegosoft.com<BR>> Subject: Re: [M3devel] platform/build_dir is a big tuple?<BR>> <BR>> <BR>> On Jan 22, 2008, at 8:29 AM, Olaf Wagner wrote:<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 <BR>> > now).<BR>> > This is a special topic reserved for adding new platforms.<BR>> <BR>> Precisely why I don't like many of the recent changes. I don't want <BR>> to build Windows interfaces and gorp for a non-Windows platform. <BR>> Jay, can you *please* back these changes out?<BR>> <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), <BR>> >> two (three) linkers (ms, mingwn, cygwin), various runtimes (msvc <BR>> >> various 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 <BR>> >> define enum up front that allows for watcom, metrowerks, <BR>> >> digitalmars, llvm 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: <BR>> >> msvcrt.dll, msvcr70.dll, msvcr71.dll, msvcr80.dll, <BR>> >> msvcr90.dll... but jmpbuf presumbly doesn't change again could <BR>> >> 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 <BR>> >> windowing 11011 -- cygwin with native threads 11001 -- cygwin <BR>> >> with native 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 <BR>> >> single combination works.<BR>> >> Compilers are very independent of headers and libs and headers <BR>> >> and libs are very independent of compilers, aside from a few <BR>> >> language extensions like __stdcall. You can generally mix <BR>> >> runtimes in the same process, just as you can mix them on the <BR>> >> same machine, you just need to be careful about what you pass to <BR>> >> what. If you call fopen, be sure pass the result back to the <BR>> >> matching fclose, malloc/free, etc. Startup code, to the extent <BR>> >> that it matters, might be a problem, but really, just avoid C++ <BR>> >> globals with constructors/destructors anyway, they are always a <BR>> >> problem. Modula-3 has its own startup code, and if you were to <BR>> >> write "main" in C and link in Modula-3 static .libs, that <BR>> >> probably doesn't work...might actually be better to play into <BR>> >> whatever the platform's C++ constructor story is, as problematic <BR>> >> as they (probably always?) are -- i.e. unpredictable/hard-to- <BR>> >> control ordering.<BR>> >><BR>> >> (bad editing...and maybe use hex for compression..)<BR>> >><BR>> >> Bringing back cminstall is almost interesting, to promptthe user, <BR>> >> or probe their system, though Quake/cm3 can probe at runtime.if <BR>> >> os == windows_nt system_cc | findstr version | findstr gcc <BR>> >> else system_cc | findstr visual c++else system_cc | grep <BR>> >> version | grep gcc else system_cc | grep visual c++end<BR>> >><BR>> >> inefficient.<BR>> >><BR>> >> anyway, I'll merge current NT386GNU into NT386 and make it <BR>> >> chosehow 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 <BR>> >> useful knobs, and iterating throughthe combinations, without <BR>> >> creating a combinatorial explosion of source filesor Modula-3 or <BR>> >> Quake code.<BR>> >> ...Jay<BR>> >><BR>> >><BR>> >> From: jayk123@hotmail.comTo: m3devel@elegosoft.comDate: Tue, 22 <BR>> >> Jan 2008 10:48:56 +0000Subject: Re: [M3devel] platform/build_dir <BR>> >> is a big tuple?<BR>> >><BR>> >><BR>> >> Final answer? I played around with this but just can't accept <BR>> >> platforms/build_dirs like: ntx86msmsmscm3msn <BR>> >> ntx86gccgcccm3cgmsn ntx86gccgcccm3cgxn ntx86-gggggmn ntx86- <BR>> >> ggixn ntx86_mmmimmOk, I have one more name here, and then a bit <BR>> >> of a change, or a stronger statement of something I had already <BR>> >> said.NT386MINGNUOk, I think we (me!) are confusing host and <BR>> >> target, MOSTLY.And cm3 might not have them quite divided <BR>> >> appropriately.What is a "host"? What is a "target"?MinGWin and <BR>> >> Visual C++ output similar results, targetingthe same runtime <BR>> >> (usually), threading library, windowing library.There is a chance <BR>> >> for exception handling to diverge however.Well, speaking of <BR>> >> Visual C++ the C/C++ compiler and MinGWinthe gcc environment, <BR>> >> yes, very different, not interoperable.MinGWin uses what gcc <BR>> >> calls "sjlj" -- setjmp/longjmp exceptions.Very inefficient. But <BR>> >> heck, gcc doesn't support __try/__except/__finally,only C++ <BR>> >> exceptions, and interop of C++ is often not great,what with name <BR>> >> mangling and all.NT386GNU's OUTPUT uses a different runtime, <BR>> >> unless you trim dependencies, possibly a different threading <BR>> >> library, possibly a different windowing library. All this <BR>> >> probably configurable. Again exception handling is a sore point <BR>> >> in that it is the primary C runtime dependency of Modula-3. If <BR>> >> you use Cygwin but say -mno-cygwin, that means you are targeting <BR>> >> NT386. (and don't use pthreads or X Windows; behavior of <BR>> >> exceptions/setjmp/longjmp TBD -- really, need to not use the - <BR>> >> mno-cygwin headers in that case; I'll check).Perhaps m3core.dll <BR>> >> should export m3_setjmp/m3_longjmp..Either one can do a cross <BR>> >> build to the other.Two cm3.exes, two sets of outputs, that either <BR>> >> can produce.NT386 can use gcc or the integrated backend. And the <BR>> >> gcc it uses can be MinGWin or Cygwin. (theoretically and probably <BR>> >> soon reality) NT386GNU can use either as well! (also currently <BR>> >> theory, but a real possibility) It isn't GNU tools, it is GNU <BR>> >> runtime.One small area with cm3 might fall down just slightly is <BR>> >> that of cross builds where host and target have different <BR>> >> naming conventions. -lfoo vs. foo.lib, foo.o vs. foo.obj are an <BR>> >> aspect of the host and I vaguely recall that cm3 ties naming <BR>> >> convention to ostype. The appending of .exe is a target <BR>> >> characteristics, but the others are not really. Naming <BR>> >> convention is really a host thing and not a target thing.The <BR>> >> config files are a mix of host and target information, mostly <BR>> >> actually host, except for the one line that says TARGET. Most of <BR>> >> the target variation is in cm3, which always can do any, and <BR>> >> cm3cg (which might be nice to be similar, but that's another <BR>> >> matter and not likely to ever change, except when AMD64 is the <BR>> >> last architecture standing. :) )If Windows had "rpath", then SL <BR>> >> would be split between HOST_SL and TARGET_SL.As it stands, SL is <BR>> >> HOST_SL.Consider as well the various versions of Visual C++.They <BR>> >> output mostly the same, very interoperable.Consider optimization <BR>> >> switches. Host or target?Consider version of gcc or Visual C++? <BR>> >> Host or target?Well, inevitably, the host has an affect on the <BR>> >> 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+ combinations. <BR>> >> (host cygwin, host mingwin, host native) x (target nt386, target <BR>> >> nt386gnu) But generally the host is assumed not a factor. I <BR>> >> guess "LIBC" could be seperated into several options...You could <BR>> >> actually have code that needs one runtime or another, and they <BR>> >> couldlink together, depending on what they do.. This is something <BR>> >> I don't know if cm3 handles, or anything I have seen. I should be <BR>> >> able to build a static .lib, that includes some C code, that <BR>> >> imbues its clients with build time dependencies. Well, I guess <BR>> >> #pragma comment(linker) is this.So the next tasks are roughly: <BR>> >> Merge my NT386 and NT386GNU files. Switching on a variable such <BR>> >> as backend mode. Introduce a "new" (old) NT386GNU file, <BR>> >> perhaps more like what was already there. Change NT386GNU back <BR>> >> to Posix. Build NT386GNU. oh, one more point...while these are <BR>> >> two targets from cm3's point of view, they are PROBABLY the same <BR>> >> target to cm3cgand so only one is needed. I have to check if <BR>> >> configure differentiates between i686-pc-cygwin and i686-pc- <BR>> >> mingwin...but I guess it should...It might actually be profitable <BR>> >> to have two bloated cm3cg.exe's.And they should ship to \cm3\pkg <BR>> >> \m3cc\target\host or host\target and cm3 should know which to <BR>> >> run.Blech..four of them when one would suffice?The detail being <BR>> >> mainly what the paths to .libs look like, unfortunate.Possibly <BR>> >> cm3 can bridge this gap using that "broken" feature that symlinks <BR>> >> libs into the target directory,using NTFS hard links, if <BR>> >> installroot and root are on the same volume... (or symlinks on <BR>> >> Vista).Or maybe convert the paths as appropriate, hacky, but <BR>> >> saves an extra cm3cg.exe which is good to avoid. (all the more <BR>> >> reason to lump all targets into one file, so that the host x <BR>> >> target matrix collapses to just one axis, host; andthen you can <BR>> >> write stuff in Perl/Python/Java/C# to collapse that to just one, <BR>> >> except for the underlying runtime/interpreter...) Oh, cm3cg isn't <BR>> >> the issue. It is always sitting in the correct directory and <BR>> >> reads one file and writes one file, no slashes.The issue is gcc <BR>> >> as the linker. Again, this is a host issue..and cm3 or the config <BR>> >> file definitely should do the translation. - Jay<BR>> >><BR>> >><BR>> >> From: jayk123@hotmail.comTo: m3devel@elegosoft.comDate: Mon, 21 <BR>> >> Jan 2008 23:01:44 +0000Subject: [M3devel] platform/build_dir is a <BR>> >> big 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? <BR>> >> 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, <BR>> > Germany<BR>> > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 <BR>> > 45 86 95<BR>> > http://www.elegosoft.com | Gesch�ftsf�hrer: Olaf Wagner | Sitz: <BR>> > Berlin<BR>> > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: <BR>> > DE163214194<BR>> ><BR>> <BR><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=_blank>Check it out.</A> </BLOCKQUOTE><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>