Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)

[Bill Gatliff <bgat@billgatliff.com>]

Paul Mundt wrote:

> Yes, that's the easy case. It's things like perl that are the corner
> cases, and my objection comes from the fact that people think we ought to
> not have the kernel depend on perl rather than just fixing the package
> itself. Autoconf/libtool damage is an entirely different problem :-)
> 

At first glance, it seems like checkincludes.pl could be duplicated by egrep |
uniq | wc vs. egrep | wc.  Not quite sure what checkversion.pl is trying to do.

The namespace.pl script looks optional, as does export_report.pl.

So maybe we could _reduce_ dependency on perl, if there's any advantage to gain
by doing so.  But the kernel build machinery isn't dependent on very many other
systems (just tcl, bash and gcc-core), so I don't really see the point unless
you could completely eliminate perl.  And I don't see how you might do *that*
without dragging in a bunch of stuff to replace it, thereby increasing the
number of dependencies.

Any machine beefy enough to build the kernel is more than adequate to host perl
as well.  So maybe the "corner case" is situations where you're trying to build
the kernel on an overly-minimalist host--- perhaps one that you constructed
yourself using linux-from-scratch?

Not trying to fan the flames any, of course.  I'm just sayin'...

The worst for cross-building so far for me has been openssh.  And even that's
tolerable once you find your way around the autoconf stuff.  But this would be
the wrong list for that.  :)


b.g.
-- 
Bill Gatliff
bgat@billgatliff.com