public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Dan Armak <danarmak@gentoo.org>
To: gentoo-dev@gentoo.org
Cc: Seemant Kulleen <seemant@gentoo.org>,
	Martin Schlemmer <azarah@gentoo.org>
Subject: [gentoo-dev] xpatch() - new patch wrapper, aimed to replace epatch
Date: Tue, 10 Jun 2003 20:30:23 +0300	[thread overview]
Message-ID: <200306102030.31763.danarmak@gentoo.org> (raw)

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 3002 bytes --]

Hello everyone,

People using nontrivial calls to epatch(), please test this. Also cc'ing 
Azarah, the author of epatch(). Please comment.

Currently there are two patch helper functions - epatch() from eutils.eclass 
and autopatch in base_src_unpack (inherited by kde.eclass). Each has its own 
strengths and weaknesses.

Briefly, epatch can autodetect the patchlevel (ie -p0, -p1 etc) and handles 
directories containing many patches well. However, it runs patch --dry-run 
once or more for each patch, and so takes a long time (for big patchsets) to 
determine how to apply a patch.

autopatch OTOH doesn't do anything special, but is called automatically from 
base_src_unpack to patch from the files listed in $PATCHES, which allows us 
not to define an src_unpack() in an ebuild just to patch things. This is very 
useful in kde ebuilds where we can usually avoid defining any functions at 
all.

I've written xpatch() to unite the strengths of these two schemes (also adding 
some new stuff) and replace them both. I've committed an initial version into 
eutils.eclass. It accepts as arguments any amount of patchfiles and/or 
directories which are scanned for patchfiles (non-recursively, to match 
epatch's behaviour). In the latter case, only patches whose filenames contain 
_$ARCH_ or _all_ are applied, to match the most common epatch() usage.

The benefit on the user side of all this is faster patching in ebuilds that 
use e/xpatch - two or three times faster, at least in terms of cpu time.

I've tested it with simple ebuilds that only need one patch at -p0 or -p1, and 
with the xfree ebuild and its patchdir. Just replace any calls to epatch with 
xpatch. Most/all of the parameters to epatch (via E* variables) aren't needed 
anymore.

One further note: xpatch's test are rather fuzzy. Some (highly improbable imho 
;-) configs might in theory not work with it. However any such problems would 
be seen by the developer before committing the ebuild. So I don't want to 
complicate the function with various special-case checks until someone tells 
me they're needed in real-world cases.

Known issues (both of these can be fixed if requested):
- only supports unified-style diffs (because it parses the patchfiles itself a 
bit).
- the first file addressed in a patch can't have a space in its name or 
relative path (because I'm lazy).

Current features (a few more planned):
- patchdir handling like epatch's
- automatic patchlevel detection like epatch's, but doesn't use --dry-run so 
takes almost no time
- automatic patch uncompression from bzip2, gzip and zip at need. detection of 
compression is done by calling /usr/bin/file - better than epatch's file 
extension detection
- can be called from autopatch to be used automatically from all existing kde 
ebuilds that use $PATCHES

-- 
Dan Armak
Gentoo Linux developer (KDE)
Matan, Israel
Public GPG key: http://cvs.gentoo.org/~danarmak/danarmak-gpg-public.key

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

             reply	other threads:[~2003-06-10 17:30 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-10 17:30 Dan Armak [this message]
2003-06-21  9:25 ` [gentoo-dev] xpatch() - new patch wrapper, aimed to replace epatch Dan Armak

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200306102030.31763.danarmak@gentoo.org \
    --to=danarmak@gentoo.org \
    --cc=azarah@gentoo.org \
    --cc=gentoo-dev@gentoo.org \
    --cc=seemant@gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox