[oe] trying to simplify the patch/apply/pnum/striplevel jungle
Robert P. J. Day
rpjday at crashcourse.ca
Sun Jun 6 07:14:06 UTC 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
deleted
* any *other* occurrences of pnum= can be replaced by the equivalent
striplevel=
* 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.
rday
--
========================================================================
Robert P. J. Day Waterloo, Ontario, CANADA
Linux Consulting, Training and Kernel Pedantry.
Web page: http://crashcourse.ca
Twitter: http://twitter.com/rpjday
========================================================================
More information about the Openembedded-devel
mailing list