On Wednesday 25 February 2009 15:48:29 Peter Tyser wrote: > On Fri, 2009-02-06 at 18:27 -0500, Mike Frysinger wrote: > > On Friday 06 February 2009 17:01:43 Peter Tyser wrote: > > > On Fri, 2009-02-06 at 16:51 -0500, Mike Frysinger wrote: > > > > On Friday 06 February 2009 14:59:10 Peter Tyser wrote: > > > > > On Fri, 2009-02-06 at 20:06 +0100, Wolfgang Denk wrote: > > > > > > In message Peter Tyser wrote: > > > > > > > Add a mkimage_win32.exe build target which can produce a native > > > > > > > win32 mkimage executable using the MinGW toolchain. The > > > > > > > mkimage_win32.exe binary is generated when the MINGW_COMPILE > > > > > > > environment variable is defined. The mkimage_win32.exe binary > > > > > > > can be used by those who use Windows as an OS build environment > > > > > > > but don't use cygwin. > > > > > > > > > > > > Why do we need a new envrironment variable? Can we not follow the > > > > > > standard pattern ansd use CROSS_COMPILE instead? > > > > > > > > > > Most files can't be compiled with MinGW so if CROSS_COMPILE is set > > > > > to a MinGW compile errors quickly occur in the build process. > > > > > Also, it would be a bigger pain to compile u-boot + > > > > > mkimage_win32.exe. Eg: > > > > > > > > > > export CROSS_COMPILE=powerpc-linux- > > > > > export MINGW_COMPILE=i586-mingw32msvc- > > > > > make > > > > > > > > > > vs > > > > > > > > > > export CROSS_COMPILE=i586-mingw32msvc- > > > > > make > > > > > cp tools/mkimage_win32.exe ~/ > > > > > make clean > > > > > export CROSS_COMPILE=powerpc-linux- > > > > > make > > > > > > > > i think you're trying too hard. you're trying to combine three > > > > targets at once: the host system (ppc), the build system (i686 prob), > > > > and canadian cross for some other random build system (mingw). > > > > > > > > the logical step would be to only build the tools for your random > > > > other build system instead of trying to combine it all together. in > > > > other words, set the HOSTCC to your mingw compiler and only process > > > > the tools target. this is how every other package out there works > > > > and it doesnt really make sense to have u- boot be different in this > > > > regard. > > > > > > But Windows isn't really the HOSTCC, its a cross-compile target. > > > Setting my HOSTCC to a cross compiler seems just as confusing as > > > setting up 2 cross-compile targets to me. > > > > when you're only building the tools, there is no native code execution > > nor building for the target. so the HOSTCC represents the system where > > the tools compiled will be run. > > > > > The process of building would also still be slightly more complex to > > > me: > > > > that's just too bad then imo. what you're prosing is carrying > > system-specific cruft in the build system so you can avoid running `make` > > once more. that's not a scalable system and that's crap we dont want to > > see. we'll have to add all kind of weird stuff for every new random > > system someone wants to support. > > > > what i'm proposing is something that works for any system. to build > > u-boot: make CROSS_COMPILE=bfin-uclinux- ... > > to cross-compile the helper tools for some random system: > > make HOSTCC=mingw32-gcc tools > > > > if you want to avoid object file conflicts, then just use sep build trees > > with O=... like normal > > Is there any interest in getting win32 mkimage support into U-Boot? > Would it be accepted if I make any suggested changes? > > I don't want to spend any time discussing/cleaning/testing if its not > going to be accepted:) If there is interest, I'll gladly cleanup and > re-submit.
i'm interested in having it work, but i'm not the main u-boot maintainer, so i wouldnt be the one accepting/rejecting ... i would however carry it in my tree ... -mike
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
