On Sun, Jun 6, 2010 at 12:14 AM, Robert P. J. Day <[email protected]>wrote:
> 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. Yep, that sounds fine to me. I tried to do that with a number of sed scripts in the initial commits, but either I missed a few or some snuck in from merges and other commits after that went in :) Both are likely, really. -- 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
