[oe] trying to simplify the patch/apply/pnum/striplevel jungle

[Chris Larson]

On Fri, Jun 4, 2010 at 11:53 PM, Robert P. J. Day <rpjday at crashcourse.ca>wrote:

>
>  just working my way thru the OE manual and source and it's clear
> that there could be some cleanup of superfluous or deprecated patch
> info.  so can someone clarify whether my understanding of the
> following is correct?
>
> pnum/striplevel
> ===============
>
>  first, "pnum=" is deprecated and has been replaced by "striplevel="
> and, in any event, given that the default patchlevel is one, it's
> unnecessary for either of those to be there while being set to one.  i
> don't see any cleanup in the source itself, but the manual could be
> updated on that point, as in
> (http://docs.openembedded.org/usermanual/html/src_uri_variable.html):
>
> "pnum
>
>    By default patches are applied with the "-p 1" parameter, which
> strips off the first directory of the pathname in the patches. This
> option is used to explicitly control the value passed to "-p". The
> most typical use is when the patches are relative to the source
> directory already and need to be applied using "-p 0", in which case
> the "pnum=0" option is supplied."
>
>  obviously, the manual could mention that that's deprecated and
> should additionally describe striplevel.
>
>  in fact, given that there's no reference to pnum= in the OE source,
> perhaps support for (and all references to) "pnum" can be dropped
> entirely unless other (non-OE) projects still depend on it.
>
>  in any event, i can submit a patch to update the manual.
>

pnum works for compatibility reasons, but it will display a warning, with a
pointer to the new parameter to use instead.  But yes, that's correct, it
was just a rename for clarity.

patch/apply
> ===========
>
>  as i read it, "patch=" has also been deprecated and, once again, the
> manual could stand to be updated (on that same page above):
>
> "patch
>
>    Used as "patch=1" to define this file as a patch file. Patch files
> will be copied to ${S}/patches and then applied to source from within
> the source directory, ${S}."
>
>  there's still some "patch=" content in the OE source, such as:
>
> recipes/udev/udev_100.bb:SRC_URI += "file://noasmlinkage.patch;patch=1 \
> recipes/udev/udev_100.bb:           file://flags.patch;patch=1 \
> recipes/udev/udev_100.bb:
> file://mtd-exclude-persistent.patch;patch=1 \
> recipes/udev/udev_092.bb:SRC_URI += "file://noasmlinkage.patch;patch=1 \
> recipes/udev/udev_092.bb:           file://flags.patch;patch=1 \
> recipes/udev/udev_092.bb:           file://udevsynthesize.patch;patch=1 \
> recipes/udev/udev_092.bb:            file://arm_inotify_fix.patch;patch=1
> \
> recipes/udev/udev_092.bb:
> file://mtd-exclude-persistent.patch;patch=1 \
> recipes/udev/udev_097.bb:SRC_URI += "file://noasmlinkage.patch;patch=1 \
> recipes/udev/udev_097.bb:           file://flags.patch;patch=1 \
>
>  what i need clarified is the possible usage of "apply=" WRT patches.
> as i read classes/patch.bblclass, it seems like:
>
>  * any file whose name ends in either ".diff" or ".patch" is
>    considered a patch and will, by default, be processed that way
>
>  * "apply=no" is only necessary to *prevent* default
>    processing of a ".patch" or ".diff" file
>
>  * "apply=yes" is only necessary to *force* processing of a file
>    that *doesn't* end with one of those suffixes.  in short,
>    something like this is redundant:
>
>    recipes/socketcan/libsocketcan_0.0.7.bb:SRC_URI +=
>      "file://install-can_netlink.h.patch;apply=yes \ ...
>                                          ^^^^^^^^^ redundant
>
> is all that about right?
>

Yep, that's all correct.  It seemed silly to not optimize for the common
case - .diff/.patch & -p 1, so now it does so.  'patch' parameter too, still
works for compatibility, and will display a warning.

pname
> =====
>

I have no idea on this one, I'm afraid, other than what I've seen in the
source.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics