[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c384c5ea0901040223l6e53f041s9f7cdea20c9d1d8d@mail.gmail.com>
Date: Sun, 4 Jan 2009 11:23:39 +0100
From: "Leon Woestenberg" <leon.woestenberg@...il.com>
To: "Paul Mundt" <lethal@...ux-sh.org>,
"Rob Landley" <rob@...dley.net>, "H. Peter Anvin" <hpa@...or.com>,
"Leon Woestenberg" <leon.woestenberg@...il.com>,
"Embedded Linux mailing list" <linux-embedded@...r.kernel.org>,
linux-kernel@...r.kernel.org,
"Andrew Morton" <akpm@...ux-foundation.org>,
"Sam Ravnborg" <sam@...nborg.org>
Subject: Re: PATCH [0/3]: Simplify the kernel build by removing perl.
Hello,
On Sun, Jan 4, 2009 at 4:06 AM, Paul Mundt <lethal@...ux-sh.org> wrote:
> Let's look at the rationale presented so far in this thread:
>
> 1 - Being able to build the kernel natively on a constrained
> target is useful, regardless of whether it is being used for
> regression/stress testing or for headers installation or whatever
> else.
>
> 2 - Cross-compiling perl is hard.
>
> 3 - Some oddly constrained target distributions manage to ship
> with an entire toolchain yet fail to provide any implementation
> of perl.
>
> 4 - It wasn't required before.
>
> If there is anything I missed, feel free to add it to the list. It was
> difficult to extract even those 4 from the ranting.
>
2 is not hard.
5. Tool *version* dependency is hard to get right. When cross-building
30 software packages all requiring native perl, we probably need to
build a few versions of perl (native), one for each set of packages.
Regards,
--
Leon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists