On Fri, Jun 4, 2010 at 11:53 PM, Robert P. J. Day <[email protected]>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 _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
