On Tuesday 04 May 2010 14:45:07 Nguyen Thai Ngoc Duy wrote:
> On Tue, Apr 27, 2010 at 9:33 AM, Denys Vlasenko
>
> <[email protected]> wrote:
> > On Saturday 17 April 2010 21:48, Nguyen Thai Ngoc Duy wrote:
> >> 2010/4/17 Denys Vlasenko <[email protected]>:
> >> > I think a positive form, "depends on TARGET_PLATFORM_POSIX",
> >> > is better - you do not need to touch it for a gazillion of
> >> > other weird platforms it does not run on (if you ever add them).
> >> > Also, at this step, add it to every applet, not to applet groups.
> >> > The patch will be bigger, but further pathes will be smaller,
> >> > since they will only need to touch one entry whenever you make one
> >> > more applet to work on WIN - you add " || TARGET_PLATFORM_NATIVE_WIN"
> >> > for that applet.
> >>
> >> How about general features that do not depend on any applets? There
> >> are some features that won't be supported on Windows, should it be
> >> "depends on !PLATFORM_MINGW32" or "depends on PLATFORM_POSIX" for
> >> them?
> >
> > depends on PLATFORM_POSIX
>
> I've been thinking about this. Eventually any supported platform (or
> whatever you call it) must support most applets, if not all. That
> would make Config.in really messy, with most configs having "depends
> on PLATFORM_POSIX || PLATFORM_NATIVE_WIN || PLATFORM_HURD". How about
> this appoach instead? With KCONFIG_SUPPORT=defconfig.mingw32, all
> items not listed in that file will be marked "BROKEN". This helps
> users of new platforms identify which applets are good while keeping
> Config.in clean.

Or just having the defconfig enable/disable stuff, which wouldn't involve 
changing the kconfig infrastructure we inherited from the Linux kernel and 
which we have to resync with regularly.

I still have a todo item to try to push the existing busybox changes upstream.  
(It's part of my miniconfig todo item.)  This is a change that could never go 
upstream and would have to be maintained in perpetuity.

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

Reply via email to