[U-Boot] MAKEALL

[Mike Frysinger <vapier@gentoo.org>]

On Tuesday 18 October 2011 16:47:12 Wolfgang Denk wrote:
> Mike Frysinger wrote:
> > > I see no clean way to implement this - ok, we could provide an
> > > external tool / data base that maps boards or SoC names to
> > > CROSS_COMPILE/ARCH/PATH settings, which each user has to configure for
> > > his own set of tool chain settings.
> > 
> > my proposal is only for the default behavior, and it only searches $PATH.
> >  if the auto-lookup isn't what the user wants, they still can set
> > CROSS_COMPILE= themselves.  so all existing usage is unchanged.
> 
> While we are at it I would like to fix the known (to me) problems of
> the current usage - that is for example that ARCH=arm includes for
> example both little and big endian systems, which usually require
> different tool chains to be used.

at least from code sorcery (who have been defacto arm providers), their single 
toolchain includes support for both endians in one package.  the right 
output/libraries are selected with -m{big,little}-endian.

in terms of compiling all the arm in a single run, i haven't had a problem 
with my one toolchain (which defaults to little endian).  but i've been using 
the private libgcc due to the many issues (including this) that comes with 
trying to use the one provided by the toolchain.

i see that some targets do add -EB/-EL/-mbig-endian to their compiler flags in 
the respective config.mk files ...

> > to add a further bit of flexibility, i might also propose that MAKEALL
> > check the variable CROSS_COMPILE_<arch> and automatically set
> > CROSS_COMPILE to that before running `make`.  this way people can do
> > CROSS_COMPILE_arm=... CROSS_COMPILE_powerpc=... ./MAKEALL arm powerpc.
> 
> That would still be to coarse for above issue.  Also, you might want
> to use different ARM tool chains for ARMv5te systemd than for ARMv6
> and yet other ones for ARMv7a, etc.

the idea is easy to extend to CROSS_COMPILE_<soc|cpu> and perhaps even 
CROSS_COMPILE_<vendor|board>

if you're not against the concept, i can post a patch and we can go from 
there.  but i can say that the limited MAKEALL behavior is the single reason 
for my limited build testing in the past.  i wrote the buildall script after 
trying to do tree-wide changes in the last few months because running 
./MAKEALL simply does not scale.
-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/20111018/67cf36ed/attachment.pgp