[oe] trying to simplify the patch/apply/pnum/striplevel jungle
Robert P. J. Day
rpjday at crashcourse.ca
Sun Jun 6 09:14:06 CEST 2010
On Sat, 5 Jun 2010, Chris Larson wrote:
> 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.
> 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.
so while i'm working on the tougher stuff, i can easily submit a
cleanup patch or three according to the following simplifications
(some of which might not even occur in the source anywhere, these are
just general rules):
* any occurrences of pnum=1 or striplevel=1 are superfluous and can be
* any *other* occurrences of pnum= can be replaced by the equivalent
* any *necessary* occurrences of patch=1 can be replaced by apply=yes
* any *unnecessary* occurrences of patch=1 or apply=yes can be
removed; those would be cases where patching would automatically
happen, as in that previous example i gave:
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 \
does all that sound reasonable? not profoundly deep, just a first
stab at cleanup, and it would eventually be accompanied by updating
the user manual to emphasize that.
Robert P. J. Day Waterloo, Ontario, CANADA
Linux Consulting, Training and Kernel Pedantry.
Web page: http://crashcourse.ca
More information about the Openembedded-devel