On Sunday 18 April 2010 05:43:22 Nguyen Thai Ngoc Duy wrote: > On Sun, Apr 18, 2010 at 8:26 AM, Rob Landley <[email protected]> wrote: > >> Nguyễn Thái NgỠc Duy (39): > >> ar: do not filter listing if there is no extra argument > >> > >> This is a regression, not related to Windows port at all. > >> > >> Config.in: add target platform selection > >> Config.in: add target platform WIN32 > > > > No. You don't have to config busybox for arm or mips or powerpc, you > > just build it. The compiler defines macros that tell you what target > > you're building on. For example, on Linux there's: > > > > #define __linux__ 1 > > > > Do this: > > > > gcc -dM -E - < /dev/null > > That does not help at kconfig level. I need to filter out applets that > I know they will never work (or won't work for the moment). It's the > next patch that you object.
CONFIG_TASKSET doesn't build on m68k, because it hasn't got the syscall. We don't have magic in kconfig for that, we just select "n" when building that target. There are similar rough edges on sh, arm, mips, ppc, sparc, and so on. CONFIG_INOTIFYD doesn't build under Knoppix 5. CONFIG_FLASHCP, FLASH_LOCK, FLASH_UNLOCK, and FLASH_ERASEALL don't build on Ubuntu 8.04 because the flash headers aren't installed by default. When building on that host, we switch those off. CONFIG_SELINUX hardly builds _anywhere_. A dozen of our applets won't build under Red Hat 9 anymore (just too old), but rather a lot still _do_. There's no magic in Kconfig trying to figure out which version of which Linux distro on which target we're building for, because the number of combinations is INSANE. I object in principle to the approach you're taking. You can set Kconfig to something that works. Trying to teach Kconfig what works and what doesn't on every single potential build environment is a can of worms we should not open. > >> Config.in: disable all commmands when TARGET_WIN32 is selected > > > > So you're forcing the rest of us to carry annotations on every single > > command ever about what you do and don't support. > > > > Why is this our problem? > > I also force you to carry lots of workaround just for Windows. But on > the other hand, it's isolated in win32 subdirectory. Including the kconfig changes? > As for Config.in, > I don't think you need to care about those "depends on !MINGW32" (or > alike) lines. If it's really a problem, do you have any suggestions? Yeah, ship a windows defconfig file in the win32 subdirectory that's your equivalent of "allyesconfig". Where does this win32 subdirectory live, anyway? (Under "arch"?) > My last approach would be maintaining them out of mainline, what I am > doing now. I hope there is a better way than that. > > >> win32: Refuse to build on Windows/MinGW unless TARGET_WIN32 is > >> selected > > > > Wrong. > > 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"? > >> 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? > 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_... I sympathize with what you're trying to accomplish, but _dude_... 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
