Re: patch for crosstool-ng to allow easier use of 3rd party patches

["Yann E. MORIN" <yann dot morin dot 1998 at anciens dot enib dot fr>]

Heiko, All,

On Sunday 19 December 2010 16:41:21 Heiko Zuerker wrote:
> Quoting "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>:
> > Nope. I do not want to rely on magic when applying the patches. They have
> > to be applied as -p1 patches.
> 
> I don't really agree with this way of approaching things. In my mind  
> this just adds unnecessary complication and steps to the process of  
> adding patches.

Yes, I can understand. But this is needed. I won't again start yet another
patch-war, but if you blindly apply patches without checking if they still
are relevant, then you make a big, big mistake. And a patch that applies
with fuzz is no longer relevant, unless you _manually_ check it is.

And bailing out if fuzz is too high makes you notice something _might_
be wrong. Then you, as a developper, have to fix it. If it is relevant,
then fix the patch, it's quite easy:
  1) copy the sources to a reference directory
  2) apply the patch
  3) diff the copy to the patched sources
  4) iterate for all patches

This gives you a clean patchset that applies with -F1 (even -F0!) and -p1.

That's what patch-rework does. But being an automated tool, it also bails
out early if it finds a patch is too fuzzy. Maybe we could have an option
that relaxes that constraint...

> How about the -F1?
> You're using it in both the patch-rework.sh and in the functions file.
> The patches I'm using don't apply with this setting. The patches  
> aren't mine (see below) and I don't have the skill to rewrite them.

-F1 means to not apply patches which fuzz factor is bigger than 1, that
is only the first or last line of context may change. If more than one line
of context has changed, then it means the code being patch has changed too
much, and it is not safe to apply patches in automatic mode.

Maybe, I say 'maybe', you could make this change conditional, adding a
config options. I could look at it if it's conditional, but it definitely
is not going to get in if it's unconditional.

And another thing that makes your change not complete: using --dry-run is
not very foolproof, because patches may contain accumulated patches against
a same file, and that would get rejected by --dry-run, when it would apply
cleanly.

> > If you have a set of patches that do not apply with -p1, then you can have
> > a look at scripts/patch-rework.sh. It's purpose is exactly that: transform
> > a patchset of non-p1 patches into -p1 patches.
[--SNIP--]
> Unfortunately I didn't get anywhere with the patch-rework.sh script.
> These are the patches I'm trying to apply:
> http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo/src/patchsets/gcc/4.4.5/pie/

Yes, I've been porting the Gentoo patches as well, and many of them.

It's cumbersome to look at why the patch no longer applies, and whether to
keep and fix the patch, or to trash it.

Fact it, are you sure the pie patches should be applied on a pristine gcc,
or on a gcc already patched with the generic patches?

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

--
For unsubscribe information see http://sourceware.org/lists.html#faq