> 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-embedded" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
