[M3devel] platform/build_dir is a big tuple?

Wed Jan 23 03:45:43 CET 2008

Two of the types are dead and the calling convention doesn't matter.
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.

 - Jay

From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; wagner at elegosoft.comCC: m3devel at elegosoft.comSubject: RE: [M3devel] platform/build_dir is a big tuple?Date: Wed, 23 Jan 2008 02:25:39 +0000

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

> From: hosking at cs.purdue.edu> Date: Tue, 22 Jan 2008 12:54:04 -0500> To: wagner at elegosoft.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] platform/build_dir is a big tuple?> > > On Jan 22, 2008, at 8:29 AM, Olaf Wagner wrote:> > > All this may be useful during development, but it is not really> > useful for a software distribution to our users, I think.> >> > Nobody will understand it :-( We need to keep things more simple.> >> > We don't need to support everything out of the box. Instead, we should> > offer some sensible default combinations of everyhing you describe.> >> > First of all: we don't distribute cross compilers (at least until > > now).> > This is a special topic reserved for adding new platforms.> > Precisely why I don't like many of the recent changes. I don't want > to build Windows interfaces and gorp for a non-Windows platform. > Jay, can you *please* back these changes out?> > >> > Runtime and compilers used do not necessarily need to be distinguished> > by target or build dir, in many cases different cm3.cfg may suffice.> >> > Until now, threading models are also no choice that needs to be> > visible at this level. There's one default model for every target,> > and the user can change it by recompiling.> >> > And if we should really agree that changing the target naming scheme> > is a good idea, we should> >> > o use a systematic one with not more than 4 elements (better still,> > 3 (e.g. <arch>-<os>-<variant>))> > o don't use cryptic abbreviations that will confuse most people> >> > Just my 2 cents,> >> > Olaf> >> > Quoting Jay <jayk123 at hotmail.com>:> >> I'm still torn over that any NT386 target could have a choice of > >> three threading models (win32, pthread, vtalarm), two windowing > >> libraries (ms, x), two (three) compilers (ms, mingwin, cygwin), > >> two (three) linkers (ms, mingwn, cygwin), various runtimes (msvc > >> various versions, cygwin, mingwin (discouraged)) etc.> >>> >> Appending a short string of unreadable bits to BUILD_DIR is very > >> temptingin order to easily generate and test the combinatorial > >> possibilities.> >>> >> backend: 0 integrated, 1 gcc already a setting (with four values)> >>> >> ccompiler/linker: 0 ms, 1 gcc (these could be split, and could > >> allocate more bits...) maybe 00 ms, 01 cygwin, 10 ming maybe > >> define enum up front that allows for watcom, metrowerks, > >> digitalmars, llvm etc.> >> maybe use a decimal digit for all these, and 0 is reserved, maybe.> >>> >> threading: 0 win32, 1 pthreads drop vtalarm, or use two bits?> >>> >> windowing: 0 ms, 1 x> >>> >> cruntime: 0 ms, 1 cyg There is also a ming runtime, discouraged > >> There also really N ms runtimes, ming offers several: > >> msvcrt.dll, msvcr70.dll, msvcr71.dll, msvcr80.dll, > >> msvcr90.dll... but jmpbuf presumbly doesn't change again could > >> allocate multiple bits..> >>> >> cruntime I guess determines oSTYPE Win32 or Posix, thoughit loses > >> its meaning mostly, and X vs. not-X is usually decide the same...> >>> >> The three most common combinations: 00000 -- NT386 11111 -- > >> NT386GNU 11000 -- NT386MINGNU> >>> >> but several others would work 11101 -- cygwin with native > >> windowing 11011 -- cygwin with native threads 11001 -- cygwin > >> with native threads and native windowing> >> BUILD_DIR would be NT386-$(config)as a special case perhaps, the > >> three commoncases could be translated to the above strings.> >>> >> But the underlying implementation would be a few bools/enums,and > >> iterating through them would be easy, while special casingand > >> skipping deemed invalid combinations, like ms runtime and > >> pthreads,and possibly ms runtime and x windows.> >> Really, it might surprise folks, but really, basically every > >> single combination works.> >> Compilers are very independent of headers and libs and headers > >> and libs are very independent of compilers, aside from a few > >> language extensions like __stdcall. You can generally mix > >> runtimes in the same process, just as you can mix them on the > >> same machine, you just need to be careful about what you pass to > >> what. If you call fopen, be sure pass the result back to the > >> matching fclose, malloc/free, etc. Startup code, to the extent > >> that it matters, might be a problem, but really, just avoid C++ > >> globals with constructors/destructors anyway, they are always a > >> problem. Modula-3 has its own startup code, and if you were to > >> write "main" in C and link in Modula-3 static .libs, that > >> probably doesn't work...might actually be better to play into > >> whatever the platform's C++ constructor story is, as problematic > >> as they (probably always?) are -- i.e. unpredictable/hard-to- > >> control ordering.> >>> >> (bad editing...and maybe use hex for compression..)> >>> >> Bringing back cminstall is almost interesting, to promptthe user, > >> or probe their system, though Quake/cm3 can probe at runtime.if > >> os == windows_nt system_cc | findstr version | findstr gcc > >> else system_cc | findstr visual c++else system_cc | grep > >> version | grep gcc else system_cc | grep visual c++end> >>> >> inefficient.> >>> >> anyway, I'll merge current NT386GNU into NT386 and make it > >> chosehow to compile/link which are the main variables today.> >> and then decide about cygwin, but probably do like the above, > >> sinceit'll totally share code with NT386 except the naming > >> conventionsand the removal of the -mno-cygwin switch..> >>> >> I know this seems overly complicated, but it should be > >> exposableeasily enough to users by hiding the choices, presenting > >> three basic ones,and still allow all the obvious and perhaps > >> useful knobs, and iterating throughthe combinations, without > >> creating a combinatorial explosion of source filesor Modula-3 or > >> Quake code.> >> ...Jay> >>> >>> >> From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Tue, 22 > >> Jan 2008 10:48:56 +0000Subject: Re: [M3devel] platform/build_dir > >> is a big tuple?> >>> >>> >> Final answer? I played around with this but just can't accept > >> platforms/build_dirs like: ntx86msmsmscm3msn > >> ntx86gccgcccm3cgmsn ntx86gccgcccm3cgxn ntx86-gggggmn ntx86- > >> ggixn ntx86_mmmimmOk, I have one more name here, and then a bit > >> of a change, or a stronger statement of something I had already > >> said.NT386MINGNUOk, 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 > >> couldlink 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 cm3cgand 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; andthen 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". Check it out.> >> _________________________________________________________________> >> Climb to the top of the charts! Play the word scramble challenge > >> with star power.> >> http://club.live.com/star_shuffle.aspx? > >> icid=starshuffle_wlmailtextlink_jan> >> >> >> > -- > > Olaf Wagner -- elego Software Solutions GmbH> > Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, > > Germany> > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > > 45 86 95> > http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: > > Berlin> > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > > DE163214194> >> 

Need to know the score, the latest news, or you need your Hotmail®-get your "fix". Check it out. 
_________________________________________________________________
Climb to the top of the charts! Play the word scramble challenge with star power.
http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080123/ba5d0e5a/attachment-0002.html>