lkml.org 
[lkml]   [2009]   [Jan]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: PATCH [0/3]: Simplify the kernel build by removing perl.
> 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


\
 
 \ /
  Last update: 2009-01-04 17:25    [W:0.317 / U:1.068 seconds]
©2003-2014 Jasper Spaans. Advertise on this site