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

Mike Frysinger vapier at gentoo.org
Thu Feb 26 20:42:35 CET 2009


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


More information about the U-Boot mailing list