And this one too... On Monday 19 April 2010 00:43:18 Nguyen Thai Ngoc Duy wrote: > >> If you read the patch, you would see that it only refuses to build you > >> you do use MinGW compiler and not have TARGET_WIN32 set. > > > > I mean the approach of annotating magic knowledge of build environments > > in kconfig is a neverending battle that will bit rot every single release > > of OTHER people's code. > > > > For example, future versions of mingw may have these headers you need > > included in their build environment. So your workaround becomes > > irrelevant but busybox development has no way of knowing that. > > > > Did you even _try_ to submit these headers upstream to mingw and say "I > > need this to build busybox"? > > I doubt they will accept.
Then why should we? > Mingw is a compiler with mvscrt.dll as > runtime C library, not POSIX environment. MS follows "ANSI standard" > (don't ask me what it is). That's the C language specification. It's for a programming language, not an operating system. The current version (C99) is this: http://busybox.net/~landley/c99-draft.html Last I checked Microsoft mostly still followed the older one from 1989, and we use the one thats only a decade old at this point. By the way, for the whole 64 bit transition thing the relevant standard is LP64: The LP64 standard: http://www.unix.org/whitepapers/64bit.html The LP64 rationale: http://www.unix.org/version2/whatsnew/lp64_wp.html That guarantees that "long" and "pointer" are always the same size on both 32 and 64 bit systems. (Hence LP64.) Int remains 32 bits on both platforms, short is 16 bits, char is 8 bits. This standard is adhered to by Linux, all the BSDs, MacOS X, pretty much every OS out there... Except Windows: http://blogs.msdn.com/oldnewthing/archive/2005/01/31/363790.aspx They kept long and int the same size always, and use "long long" even on 64 bit systems to specify 64 bits. They did so because their binary ABI definitions sprinkled "long" in all over the place and they wanted them to stay 32 bits without rewriting their headers because they're lazy and hilariouusly bad at programming. So what you're saying is you want to crap 32-bit windows compatability code all over bsybox, but never have any hope of supporting 64 bit windows without a massive rewrite of busybox that makes it harder for us to work on MacOS X and Linux and BSD and basically everywhere else. Why is this interesting again? > Adding headers does not solve the problem, > they will have to implement missing functions too, and they are > compiler guys. If your build environment is broken, fix your build environment. > >> >> Very basic stuff just enough to make a succesful build. You > >> >> will have a nice 52K busybox.exe, with no applets. > >> > > >> > On Linux, or allnoconfig is 10k. (I'm not sure _why_ it's 10k, I > >> > thought it used to be more like 5k, but oh well...) > >> > >> Well, size does not matter that much to me, > > > > THEN WHY THE HELL ARE YOU USING BUSYBOX? > > Source code size matters, not binary size. Busybox source is more > compact, and features can be tweaked in/out easily. That would help > the port (even isolate features that won't work). Our source code is small EXACTLY because we haven't polluted it with this kind of stuff over the years. That's the reason. We think through the minimum we can get away with, rip OUT existing stuff that's already working but which we don't need. > >> at least for now. Who > >> knows, I might do size optimization someday if its functionality is > >> good enough. > > > > *whimper* > > > > It... The goal of busybox... Small, simple, and self-contained. That's > > the whole point. You've managed to violate all three of those design > > goals in this message. I'm in _awe_... > > It's still simple (I hope) Beign "simpler than anything else on windows" is like being the most agile quadraplegic. I really, really, really, really don't want to get any of Windows on code I have to look at. > and self-contained (unique feature that > separates busybox from cygwin/msys). I can't test your changes. I will break your changes if I ever modify busybox again. This your code will bit-rot unless you sit there and baby-sit it forever. You're also imposing rules on my future changes. "Don't do X or it'll break windows". This is something about which I WILL NEVER CARE unless paid to do so. > And if you care about size, If? Dude. You're on the busybox list. You're implying that we don't care about size. How clueless do you get? I think what you're trying to implying is that if we don't care about supporting windows, obviously we don't care about small code size, which is false and insulting. > busybox is much smaller than MSYS or Cygwin base install. That's like saying castor oil is tastier than motor oil. Obviously castor oil is the ultimate beverage then. > Not "small" > by Linux standard, you know it's Windows. That's not an excuse. We trade off size, simplicity, features, and speed. We're trying to optimize for all four, but we tend to weight the first two more heavily becase there's lots of others out there that weight the last two more heavily. (That's what distinguishes us from them.) Yo're promising to make busybox bigger and more complicated. In exchange, you're promising the "feature" of limited windows support. Except Cygwin already built most of busybox last I checked (2006), so the value of this feature has multiple levels of "dubious" built-in. Rob -- Latency is more important than throughput. It's that simple. - Linus Torvalds _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
