[U-Boot] [PATCH][RFC] Add native win32 mkimage support

Mike Frysinger vapier at gentoo.org
Sat Feb 7 00:27:30 CET 2009


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
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20090206/bc224919/attachment.pgp 


More information about the U-Boot mailing list