[PATCH 00/39] Windows port, base and archival/

[Nguyen Thai Ngoc Duy]

On Sun, Apr 18, 2010 at 7:32 PM, Rob Landley <rob at landley.net> wrote:
>> 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".

I'm OK with that too. Denys, should I go with this approach?

> Where does this win32 subdirectory live, anyway?  (Under "arch"?)

At top level directory.

>
>> 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"?

I doubt they will accept. 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). Adding headers does not solve the problem,
they will have to implement missing functions too, and they are
compiler guys.

>> >> 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).

>> 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) and self-contained (unique feature that
separates busybox from cygwin/msys). And if you care about size,
busybox is much smaller than MSYS or Cygwin base install. Not "small"
by Linux standard, you know it's Windows.
-- 
Duy