Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756760AbZADQWd (ORCPT ); Sun, 4 Jan 2009 11:22:33 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751643AbZADQWW (ORCPT ); Sun, 4 Jan 2009 11:22:22 -0500 Received: from mail-bw0-f21.google.com ([209.85.218.21]:44234 "EHLO mail-bw0-f21.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751441AbZADQWV (ORCPT ); Sun, 4 Jan 2009 11:22:21 -0500 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=CqyWLUAxILyc+dVgXkdNTWG7tieB/ekjCWwHkLr7X8c5jdbjQ01LqQvuxF72GeBIPV Iprsk7eFWaziaQguXM42xEQLA+j48XFc7hUZrwZGersyHOSk5Ik0lreZRPXdY3+zd9L8 7I2P7pGpRFXNtJaOWzfLLBQjm4uywCqjdN8Cs= Message-ID: <6784529b0901040822q1a64e2dfi64f0da781f2a8223@mail.gmail.com> Date: Sun, 4 Jan 2009 19:22:18 +0300 From: "Vladimir Dronnikov" To: "Paul Mundt" , "Rob Landley" , "H. Peter Anvin" , "Leon Woestenberg" , "Embedded Linux mailing list" , linux-kernel@vger.kernel.org, "Andrew Morton" , "Sam Ravnborg" Subject: Re: PATCH [0/3]: Simplify the kernel build by removing perl. In-Reply-To: <20090104030619.GA21466@linux-sh.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200901020207.30359.rob@landley.net> <495FEEAF.5020005@zytor.com> <200901032006.47652.rob@landley.net> <20090104030619.GA21466@linux-sh.org> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2263 Lines: 60 > 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. OK, let's see. > If you have enough space and CPU power and > complete build environment to crunch away at the kernel for stress > testing natively, you can do the same with building perl and negating > point #2. It seems you meant "If you have enough space ... for stress testing natively, you _MUST ALSO_ do the same with building perl _TO JUST_ negate point #2". From this point of view your further arguments are obvious. > > #2 is another byproduct of your environment and generally a non-issue. > So you put a constraint on environment to build kernel. Not on a specific version of shell or gcc. But require SANE environment in rhetoric sence. In the absence of clear specification of sane environment it _IS_ an issue. Or simply: "sane" now reads "perlful enough"? > > If there is anything I missed, feel free to add it to the list. > The rationale of changes being proposed is to keep people able to make their choice on how to build and use their environment. If the code, which now has to be generated by perl scripts, was shipped with linux*.tar.bz2, I'd nullify the majority of my objections. Please, DO NOT require this code to be BUILT, and many would again be happy. You see, the total question is then reduces to some changes in makefiles (eliminating FORCE prerequisites). Otherwise you just force the number of people to invent and maintain "regress" patches, which is counter-progressive in all sences. Best regards, -- Vladimir V. Dronnikov -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/