Re: PATCH [0/3]: Simplify the kernel build by removing perl.

[Rob Landley <rob@landley.net>]

On Monday 12 January 2009 03:41:22 Paul Mundt wrote:
> Personally I think perl (and python for that matter) is a terrible
> language and I wouldn't use it for anything of consequence, but again,
> that is my personal opinion and has nothing to do with regards to the
> build system and whether it was the better tool for the job as perceived
> by the people that elected to implemented infrastructure using it. I
> choose not to use it for my own projects, but I have no qualms with those
> that do.

Apparently you have qualms with people who chose to reimplement the perl bits 
in one of the languages kernel developers already needed to know this time 
last year (shell, C, make).

> The kernel does not need to provide justification for every change that
> goes on as long as there is a reasonable attempt not to break things for
> other people.

I submitted a change, you insisted that I justify it to your satisfaction.  
That pretty much summarizes your participation in this thread.

> The onus is (and always has been) on you to demonstrate why
> perl is an unreasonable dependency to push on embedded developers, and
> you have failed utterly at demonstrating this in any sort of coherent
> fashion.

Large additional dependencies without benefit are unreasonable.  My primary 
objection to perl is that it happens to be an additional large dependency 
without a correspondingly large benefit.

Your position is not internally consistent.  There was no need to scrutinize 
it when it went in, but there is a need to scrutinize patches reimplementing 
those bits without it.  You don't need the word "perl" in that sentence for 
your position to be a touch unbalanced.

> I will repeat, there has not been a single coherent argument against what
> makes perl inherently incapable of being supported.

I didn't say it was incapable of being supported.  We're _capable_ of 
reimplementing the entire kernel in perl except for a microkernel interpreter 
running on the bare metal.  Or cobol.  Sun spent some time trying to do one in 
Java a few years back.

"It can be done" and "It's a good idea" are two completely different criteria.

> Every single thing
> you have presented as a rebuttal has been your personal preference, which
> in this case is simply irrelevant.

Stop getting so hung up on the word "perl".  Did you ever notice the _shipped 
files in the kernel so you don't have to have lex or yacc installed?  That's 
been kernel policy for how many years now?  The arguments about "dash vs bash" 
when reviewing the shell versions of these scripts are a similar impulse: 
trying to reduce unnecessary dependencies.

My first version of the timeconst patch didn't remove the perl script that 
generated the file, it simply shipped the pregenerated .h file so it was 
possible to _build_ without perl.  That was not sufficient for technical 
reasons (due to the two architectures that allow you to enter arbitrary 
values), so I redid the patch.

Rob