On Mon, Jan 12, 2009 at 04:03:32AM -0600, Mark A. Miller wrote: > On Mon, Jan 12, 2009 at 3:41 AM, Paul Mundt <lethal@xxxxxxxxxxxx> wrote: > > I will repeat, there has not been a single coherent argument against what > > makes perl inherently incapable of being supported. > > You're right, this thread is worthless with that particular mindset, > Paul. Not, perhaps that the tool in question is brittle, and prone to > potentially break on more architectures than the current make and C > code infrastructure, no, your stance is, unless Perl *cannot* run on > that particular architecture and environment, it has a valid place in > the kernel because it was chosen by certain developers. > Nonsense. I singled out that point because that was the one you were replying to in the first place. I itemized the objections in this thread earlier on and attempted to indicate why they were not applicable in this context, and asked people to add to it if anything had been overlooked. If you want to play semantics, do it somewhere else. If the tool is brittle and constantly breaking, we will see bug reports, and re-evaluate the support position. This hasn't happened to date in the context of the kernel build system, so there is no point in even bringing this up. Anyways, given that you haven't contributed anything to the kernel and are therefore perhaps unfamiliar with how things work, I attempted to show you why the kernel made the decision it did and what it would take to change that. You have from the beginning only wanted to focus on idle semantics and refused to re-evaluate your own position on what precisely it is you find to be problematic in the first place. So, with that, I am done with this thread, and it seems the key takeaways from this entire thing has only been a few new lines in my killfile. It's regrettable you didn't get anything else out of this thread, though I think both the kernel and embedded linux will survive. -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
