Re: [U-Boot] [PATCH/next v3 27/28] Add support for building native win32 tools
Dear Peter Tyser, In message 1239749550.24099.147.ca...@localhost.localdomain you wrote: ... #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. It seems there were no really clever ideas, or did I miss them? Hm.. actually I lost track of which patch is missing. Could you please send me a pointer to the latest and greatest version? Sorry thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Men don't talk peace unless they're ready to back it up with war. -- Col. Green, The Savage Curtain, stardate 5906.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH/next v3 27/28] Add support for building native win32 tools
Hi Wolfgang, #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. It seems there were no really clever ideas, or did I miss them? Hm.. actually I lost track of which patch is missing. Could you please send me a pointer to the latest and greatest version? Sorry thanks. The original v3 of Add support for building native win32 tools has actually been merged already. After merging the patch, you had requested a cleanup patch to which I responded with the patch's rationale as well as a possible (in my opinion) dirtier cleanup. No one else suggested a cleaner way to implement the change, so what is currently committed should be correct. I'm still open to clever ideas if anyone has one though:) Thanks, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH/next v3 27/28] Add support for building native win32 tools
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-pty...@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 pty...@xes-inc.com --- 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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH/next v3 27/28] Add support for building native win32 tools
On Tuesday 14 April 2009 18:52:30 Peter Tyser wrote: On Sat, 2009-04-04 at 01:20 +0200, Wolfgang Denk wrote: In message Peter Tyser 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 pty...@xes-inc.com --- 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. i prefer #1 as well ... you covered the reasons fairly well, thanks -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH/next v3 27/28] Add support for building native win32 tools
Dear Peter Tyser, In message 1236988492-21295-28-git-send-email-pty...@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 pty...@xes-inc.com --- 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? Added, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Is the glass half empty, half full, or twice as large as it needs to ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
