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

Nguyen Thai Ngoc Duy pclouds at gmail.com
Sat Apr 17 11:19:07 UTC 2010


2010/4/17 Denys Vlasenko <vda.linux at googlemail.com>:
>>  Config.in: add target platform selection
>>  Config.in: add target platform WIN32
>
> This looks like a correct approach for this.
> Let's choose a good name for it. TARGET
> often assumes architecture, maybe we should call it
> TARGET_PLATFORM? Regarding WIN32 part, since there

Or even shorter, PLATFORM (i.e. PLATFORM_POSIX)?

> are Cygwin-like POSIX-like emulation layers, WIN32
> might be  ambiguous. Maybe NATIVE_WIN[DOWS]?
> OTOH, TARGET_PLATFORM_NATIVE_WIN is a bit long...
> but for now, it's the name which looks best to me.

Maybe I should change it back to PLATFORM_MINGW32. It's clear. And if
someone ports this to MS Visual Studio, we can deal with it later.

>>  Config.in: disable all commmands when TARGET_WIN32 is selected
>>  win32: Refuse to build on Windows/MinGW unless TARGET_WIN32 is
>>    selected
>
>  menu "Runit Utilities"
> +       depends on !TARGET_WIN32
>
> 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.

Yeah. That change was from the beginning, when I just have "config
MINGW32" without selection (i.e. no TARGET_POSIX).

>>  win32: add missing system headers
>
> This should not be added yet, see below.
>
>>  platform.h: support MinGW port
>>  win32: add termios.h
>
> This should not be added yet, see below.
>
>>  win32: add mingw.h
>>  libbb.h: support MinGW port
>>  win32: platform.h: add bswap_xx()
>>  libbb: exclude files that will not compile on Windows
>
> You are doing it wrongly. Instead, go to libbb/Kbuild
> and replace
>
> lib-y += get_console.o
>
> with
>
> lib-(TARGET_PLATFORM_POSIX) += get_console.o

Agree.

>>  libbb: update messages.c to support Windows
>>  win32: Import fnmatch source
>
> Starting from this, you have mostly things which definitely should not
> go in yet.
> First batch of patches should ONLY enable building on WIN,
> even if the result can build only "true", "false" and "basename" applets.
> (Not that it IS that bad, I think you will have more than that).
> Let's merge things up to this intermediate point,
> and then continue.

That was my intention (although this series has two parts: one to
build on win, one to enable archival/, just to demonstrate how it
changes other applets).

In order to build, it needs lots of stubs functions. I could have made
true (empty) stubs for the first part (building on win), then replace
stubs with implementation later. But I was lazy so I put impl in place
where they should have been only stubs.

>>  win32: set binary I/O mode by default
>>  win32: add sleep()
>>  win32: add mkstemp()
>>  win32: add gettimeofday()
>>  win32: add pipe()
>>  win32: add gmtime_r()
>>  win32: add localtime_r()
>>  win32: add getpwuid()
>>  win32: add signal routines and SIGALRM support
>>  win32: add function to map windows errors to posix ones
>>  win32: add link()
>>  win32: add strsep()
>>  win32: add realpath()
>>  win32: add get_busybox_exec_path(), which is bb_busybox_exec_path
>>  win32: add mkdir()
>>  win32: add waitpid()
>>  win32: add fcntl()
>>  win32: add poll()
>>  win32: add getenv(), setenv(), unsetenv() and clearenv()
>>  Makefile: support building executable with extension
>>  Makefile: support building on Windows using MinGW compiler
>>  Add README.win32
>
> After first part will be merged, next patchset should add a small set
> of compat glue, and WIN-enable a few applets which are becoming buildable
> because of that glue. This way, the patchsets will be easier to understand
> and review.

OK.

> In general, looks acceptable. There were some good comments
> from other people, please take those which you agree with into account
> and send a 1st patchset for merging when you have it.

Their comments are really appreciated. I'm redoing the patches in the moment.
-- 
Duy


More information about the busybox mailing list