[M3devel] NT386/NT386GNU/NT386MINGNU?

[Jay]

ps: NT386MINGNU really does not capture it -- it should like NT386_GNUTOOLS or NT386_GCCBACKEND
As I've said, there's a bunch of independent variables, and precanned combinations are nice to have, but hard to chose just which ones and hard to name them...
 
 - Jay


From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Mon, 28 Jan 2008 18:54:47 +0000Subject: [M3devel] NT386/NT386GNU/NT386MINGNU?


NT386/NT386GNU/NT386MINGNU My "vision" of these is pretty much in now.My weirdo target vs. configuration split.They are all TARGET = NT386. That's the "odd" part.TARGET = NT386GNU doesn't really mean anything.BUILD_DIR varies.OS_TYPE varies.Some other things vary.Does it suck or is it ok or is it great?Should they just be targets instead?This question is really aimed at the people who work on it, who have added new targets in the past, and who have perhaps thought about the SOLsun vs. SOLgnu split.How do you specify which you want?There are a few ways. Just use one usual cm3.cfg file next to cm3.exe (granted, you have to have around like four files, since they share code, NT386 and NT386GNU includes NT386.Common, NT386MINGNU includes NT386). or set the M3CONFIG variable; I've been doing that, right into the source tree. Or possibly CM3_TARGET + CM3_OSTYPE + CM3_GCC_BACKEND   The Python code sniffs those. I've been trying that too. Or uname.   Again the Python code sniffs.In the compiler, TARGET = NT386 + OS_TYPE == POSIX means  Cygwin means a larger jmpbuf. Sleazy or reasonable? I think reasonable.There are still missing parts but it is taking shape.NT386GNU now builds, but you can't run the results at all, they crash.Been there before. :)(But it's obvious where to start here -- fix Upthread.i3.)m3makefiles have to cope, at least in m3core.They always did. You know, there are directories named POSIX, NT386, cygwin, pthread.That is, neither include(OS_TYPE) nor include(TARGET) were ever always correct.Sometimes there was special logic.Now there is just slightly more logic.Reasonable?One bit I feel guilty about is probably too much dependency on OS_TYPE.Some of that should probably be on C_LIBRARY and OS_TYPE should fall away ifC_LIBRARY / THREAD_LIBRARY / WINDOW_LIBRARY are used.I changed them from 0 and 1 to more readable like MS, GNU, X, CYG.There's also C_COMPILER = MS or GNULINKER = MS or GNU The primary users of these variables are NT386.Common.NT386GNU, NT386, NT386MINGNU are little stubs that set some variables and include it.Naming conventions isn't working correctly right now, must have been some oversight by me.Still much to do.Folks who favor one coniguration or the other should benchmark the build times.I should report them.The integrated backend is FAST.Cygwin is SLOW. For goodness sakes, look at how it implements fork().  It does an immediate selective copy, erring toward copying stuff.  Yeah, it's nice and impressive that it even works, I realize.MinGWin is in betwen. AND you /should/ be able to target the Cygwin runtime using the integrated backend, and either compiler/lnker.That is, if you really want those forward slashes, and a fast build, that should be totally doable.I was thinking of making NT386FASTGNU, but it's not clear if it is builds fast or runs fast -- builds fast.Well, a native build of that would be in between. cm3 would still pay for Cygwin, but the backend would still be faster for most of its work. :) later, - Jay

Helping your favorite cause is as easy as instant messaging. You IM, we give. Learn more. 
_________________________________________________________________
Need to know the score, the latest news, or you need your Hotmail®-get your "fix".
http://www.msnmobilefix.com/Default.aspx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080128/4c9cff25/attachment-0002.html>