Re: what exactly is a "patch," anyway?

[Dan Kegel <dank at kegel dot com>]

Robert P. J. Day wrote:
>   it may be that i've just misunderstood the fundamental nature of a
> crosstool "patch."  until now, i've always thought of it as an actual
> bug or deficiency in a particular package that is corrected (ideally
> temporarily) by a crosstool patch.  (the CT web page strongly implies
> that patches are created to address actual errors:  "Each patch starts
> off with links to the appropriate discussions and/or bug reports, and
> shows the error it fixes."  so far, so good.
>
>    in a perfect world, you would of course try to push those patches
> upstream so that they're eventually incorporated which means, over
> time, you'd like to see the number of patches being reduced steadily
> as the version number increases. (yes, i'm flogging the obvious.)

This is all correct.

>   however, in looking at those arch-dependent makefiles, it wasn't
> clear to me that setting the compile options was an actual error.  i
> had assumed that, since the kernel programmers put that in, it was
> there for a purpose, so it wasn't really a bug.

I only want to fix it if it's a bug.

>   with that understanding, it seemed to me that creating a patch for
> that wouldn't be so much addressing an actual error as simply
> "hacking" a software package to make it crosstool-compatible, and
> that's what i thought was going on.
>
>   if those options are actually bad things, then i have no objection
> to the notion of a patch to get rid of them.  but does the concept of
> a patch also extend to simply modifying a perfectly working package so
> that crosstool can work with it?

No.
- Dan

--
Trying to get a job as a c++ developer?  See http://kegel.com/academy/getting-hired.html

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com