From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Tyser Date: Tue, 14 Apr 2009 17:52:30 -0500 Subject: [U-Boot] [PATCH/next v3 27/28] Add support for building native win32 tools In-Reply-To: <20090403232058.A750083797DC@gemini.denx.de> References: <1236988492-21295-1-git-send-email-ptyser@xes-inc.com> <1236988492-21295-2-git-send-email-ptyser@xes-inc.com> <1236988492-21295-3-git-send-email-ptyser@xes-inc.com> <1236988492-21295-4-git-send-email-ptyser@xes-inc.com> <1236988492-21295-5-git-send-email-ptyser@xes-inc.com> <1236988492-21295-6-git-send-email-ptyser@xes-inc.com> <1236988492-21295-7-git-send-email-ptyser@xes-inc.com> <1236988492-21295-8-git-send-email-ptyser@xes-inc.com> <1236988492-21295-9-git-send-email-ptyser@xes-inc.com> <1236988492-21295-10-git-send-email-ptyser@xes-inc.com> <1236988492-21295-11-git-send-email-ptyser@xes-inc.com> <1236988492-21295-12-git-send-email-ptyser@xes-inc.com> <1236988492-21295-13-git-send-email-ptyser@xes-inc.com> <1236988492-21295-14-git-send-email-ptyser@xes-inc.com> <1236988492-21295-15-git-send-email-ptyser@xes-inc.com> <1236988492-21295-16-git-send-email-ptyser@xes-inc.com> <1236988492-21295-17-git-send-email-ptyser@xes-inc.com> <1236988492-21295-18-git-send-email -ptyser@xes-inc.com> <1236988492-21295-19-git-send-email-ptyser@xes-inc.com> <1236988492-21295-20-git-send-email-ptyser@xes-inc.com> <1236988492-21295-21-git-send-email-ptyser@xes-inc.com> <1236988492-21295-22-git-send-email-ptyser@xes-inc.com> <1236988492-21295-23-git-send-email-ptyser@xes-inc.com> <1236988492-21295-24-git-send-email-ptyser@xes-inc.com> <1236988492-21295-25-git-send-email-ptyser@xes-inc.com> <1236988492-21295-26-git-send-email-ptyser@xes-inc.com> <1236988492-21295-27-git-send-email-ptyser@xes-inc.com> <1236988492-21295-28-git-send-email-ptyser@xes-inc.com> <20090403232058.A750083797DC@gemini.denx.de> Message-ID: <1239749550.24099.147.camel@localhost.localdomain> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Wolfgang, On Sat, 2009-04-04 at 01:20 +0200, Wolfgang Denk wrote: > Dear Peter Tyser, > > In message <1236988492-21295-28-git-send-email-ptyser@xes-inc.com> you wrote: > > Add support for compiling the host tools in the tools directory using > > the MinGW toolchain. This produces executables which can be used on > > standard Windows computers without requiring cygwin. > > > > One must specify the MinGW compiler and strip utilities as if they > > were the host toolchain in order to build win32 executables, eg: > > > > make HOSTCC=i586-mingw32msvc-gcc HOSTSTRIP=i586-mingw32msvc-strip tools > > > > Signed-off-by: Peter Tyser > > --- > > README | 10 ++++++ > > include/image.h | 2 + > > include/libfdt_env.h | 12 +++++++ > > tools/Makefile | 23 ++++++++++---- > > tools/mingw_support.c | 79 +++++++++++++++++++++++++++++++++++++++++++++++++ > > tools/mingw_support.h | 51 +++++++++++++++++++++++++++++++ > > tools/mkimage.h | 5 +++ > > tools/os_support.c | 24 +++++++++++++++ > > tools/os_support.h | 29 ++++++++++++++++++ > > tools/ubsha1.c | 3 ++ > > 10 files changed, 231 insertions(+), 7 deletions(-) > > create mode 100644 tools/mingw_support.c > > create mode 100644 tools/mingw_support.h > > create mode 100644 tools/os_support.c > > create mode 100644 tools/os_support.h > > I'm not happy about this os_support thingy, especially since it will > always be compiled, even if not needed in 99.99% of the cases. Maybe > you have a better idea and can send a cleanup-patch? The 2 options that come to mind are: 1. Keep the current method of unconditionally compiling os_support.c, which will in turn include any os-specific files. 2. Move the logic of determining which os-specific files are compiled into the Makefile. Something like: ifneq (,$(findstring WIN32 ,$(shell $(HOSTCC) -E -dM -xc /dev/null))) SFX = .exe +OS_SUPPORT_FILES = mingw_support.c else SFX = +OS_SUPPORT_FILES = endif and then replace references of "os_support.c" with "$(OS_SUPPORT_FILES). (Or something along those lines). #1 is ugly in that 99.99% of the time an empty os_support.c file is processed. #2 is ugly in that the Makefile method to determine a target OS is somewhat hokey and will only get hokier if/when additional OS targets are supported. I'd vote for #1 as I think the wasted time of processing os_support.c is a drop in the bucket and it seems a bit cleaner than hacking up the Makefile. If others have any clever ideas let me know. Best, Peter