[M3devel] platform/build_dir is a big tuple?

Tue Jan 22 15:29:04 CET 2008

I know, I've heard it many times from smart people, but sorry I can't resist. I will strive for a balance.

In particular I'm thinking

NT386
  sets a few globals as described
  include NT386.commonNT386GNU
  sets a few globals as described
  include NT386.commonNT386MINGNU
  sets a few globals as described
  include NT386.common
NT386.common will not be the simplest.

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

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).

 - Jay

> Date: Tue, 22 Jan 2008 14:29:22 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] platform/build_dir is a big tuple?> > 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.> > 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> 
_________________________________________________________________
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/20080122/f57ec8a4/attachment-0002.html>