[M3devel] platform/build_dir is a big tuple?

[Jay]

This is essentially in now.
 
I understand all those points, but there are pluses and minuses either way.
 
Including:
 
> 3 (e.g. <arch>-<os>-<variant>))
 
"variant", that's space for arbitrary variation, it's not one variable.
This scheme acknowledges two common variables and leaves slush to try to cope with what else there is.
Of course, it would be a big advance over what is there.
 
And yes I realize you lose somehow one way or another.
 
Anyway, if what I have is acceptable, or shows an acceptable direction that is *almost* complete (it is definitely not quite complete, since Cygwin isn't active yet), I can start winding down this topic. :)
 
The scheme I have..I kind of already said this..TARGET will always be NT386, and it is configurable. Three of the configurations are recognized and given made up short readable build_dir.To me, from the user perspective, build_dir is a critical aspect of target, so you can kind of give the appearance of targets without adding full scale new targets, which I realize would be "ok". The rest, if you try them, get mechnical build_dir. What I haven't worked out yet is, like..before there was the TARGET/CM3_TARGET environment variables.
Those should probably remain and get translated..which actually pretty much already works -- the environment variable will map not to a target, but to a config file name, and it will handle everything. I haven't tried this. I left the old targets for temporary compat. Later...
 
arch-os-variant is fine
I'd like to check what the four element gnu configurations.
arch-os-variant won't apply for the two "new" targets I'm working on presumably, since they derive from the existing NT386.
I assume given NT386, and essentially NT386GNU, nobody would argue for introducing I386_NT_MINGWIN or I386_NT_CYGWIN, but maybe. And yes I know, sorry, I'm being a bit of a jerk, asking for something, getting it, and then not taking it. If people do want I386_NT_MINGIN or X86_NT_MINGNU, ok with me.
 
 - Jay
 


From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3devel at elegosoft.comDate: Tue, 22 Jan 2008 14:29:04 +0000Subject: Re: [M3devel] platform/build_dir is a big tuple?


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.commonNT386.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. Play now! 
_________________________________________________________________
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/72ad2224/attachment-0002.html>