On 19 September 2011 01:40, Jeremiah Dodds wrote:

If I'm wrong, and there's a standard way of doing this within PKGBUILDs, awesome. Assuming I'm not,  I think the best you could do would be to not compile at all if the version you'd be compiling is the same as what's installed on your system, which you may already be doing.

You're not wrong, at least not on one account (the one you mentioned first). 1. Keep buildscripts locally and update the package manually (this is a standard) You will no longer depend on auto-update mechanisms (yaourt et al) based on package updates from package maintainers, but keep the buildscripts on your system for yourself. You will then initiate makepkg as usual, and provided the PKGBUILD conforms to GIT packaging standards, the checkout itself will always be there and will be updated as and when needed. 2. There's no standard "caching" location for vcs packages However, you can simply adopt your own convention across PKGBUILDs that you use. One example is to have a standard location to keep all vcs checkouts, and refer to the respective dir in there and make your checks from within the PKGBUILD. -- GPG/PGP ID: 8AADBB10

Many thanks to all of you, I'm trying them out. So the point is to never clean the code tree, nor cleaning those compiled objects. However I think re-configuring is not always needed, which results in lots of rebuilding. So It's better to decide myself when it's needed? Philipp Überbacher writes:

Excerpts from XeCycle's message of 2011-09-18 17:33:56 +0200:

...

Hi, I build Emacs from git quite frequently, about twice a month or so. However the PKGBUILD from AUR rebuilds everything each time, which takes too many time I think. Perhaps Emacs is small, but I think there should be a way to prevent too many rebuilds --- is that possible?

1. Don't use -c (clean)

I already did it.

2. Comment line 47 and 48 (PKGBUILD-git.proto), uncomment if you want a clean build.

Well, this is my PKGBUILD-git.proto: 43 # 44 # BUILD HERE 45 # 46 ./autogen.sh 47 ./configure --prefix=/usr 48 make Do you mean commenting 46 & 47? -- Carl Lei (XeCycle) Department of Physics, Shanghai Jiao Tong University OpenPGP public key: 7795E591 Fingerprint: 1FB6 7F1F D45D F681 C845 27F7 8D71 8EC4 7795 E591

Lukas Fleischer writes: [...]

...

...

2. Comment line 47 and 48 (PKGBUILD-git.proto), uncomment if you want a clean build.

Well, this is my PKGBUILD-git.proto:

43 # 44 # BUILD HERE 45 # 46 ./autogen.sh 47 ./configure --prefix=/usr 48 make

Do you mean commenting 46 & 47?

---- $ sed -n '47,48p' /usr/share/pacman/PKGBUILD-git.proto rm -rf "$srcdir/$_gitname-build" git clone "$srcdir/$_gitname" "$srcdir/$_gitname-build" ----

You should upgrade abs to 2.4.3-1.

$ LC_ALL=C pacman -Qo /usr/share/pacman/PKGBUILD-git.proto /usr/share/pacman/PKGBUILD-git.proto is owned by abs 2.4.3-1 What's up? -- Carl Lei (XeCycle) Department of Physics, Shanghai Jiao Tong University OpenPGP public key: 7795E591 Fingerprint: 1FB6 7F1F D45D F681 C845 27F7 8D71 8EC4 7795 E591

Lukas Fleischer writes:

On Tue, Sep 20, 2011 at 06:02:21PM +0800, XeCycle wrote:

[...]

...

...

...

Well, this is my PKGBUILD-git.proto:

43 # 44 # BUILD HERE 45 # 46 ./autogen.sh 47 ./configure --prefix=/usr 48 make

Do you mean commenting 46 & 47?

---- $ sed -n '47,48p' /usr/share/pacman/PKGBUILD-git.proto rm -rf "$srcdir/$_gitname-build" git clone "$srcdir/$_gitname" "$srcdir/$_gitname-build" ----

You should upgrade abs to 2.4.3-1.

$ LC_ALL=C pacman -Qo /usr/share/pacman/PKGBUILD-git.proto /usr/share/pacman/PKGBUILD-git.proto is owned by abs 2.4.3-1

What's up?

You either modified that file (use `pacman -S abs` to reinstall the package in that case) or use a weird editor with weird line numbering.

Oops, I got it. I used `nl', which ignored blank lines. -- Carl Lei (XeCycle) Department of Physics, Shanghai Jiao Tong University OpenPGP public key: 7795E591 Fingerprint: 1FB6 7F1F D45D F681 C845 27F7 8D71 8EC4 7795 E591

On Mon, Sep 19, 2011 at 11:36 AM, C Anthony Risinger wrote:

2011/9/19 Lukáš Jirkovský :

...

On 18 September 2011 17:33, XeCycle wrote:

...

Hi, I build Emacs from git quite frequently, about twice a month or so. However the PKGBUILD from AUR rebuilds everything each time, which takes too many time I think.  Perhaps Emacs is small, but I think there should be a way to prevent too many rebuilds --- is that possible?

I don't know which package you are using, but in my opinion the best approach is the following:

Look in the PKGBUILD and change "cd $srcdir/some_build_directory" (which is most likely created git clone) to a directory where the sources are downloaded (in most cases it's "$srcdir/$_gitname"). Now when you build package using makepkg, only the updated sources are rebuilt.

Generally, it's a good idea to read and understand the PKGBUILD before building. Then it's pretty simple to edit it in way which allows incremental builds.

If you would have any problems with editing this particular PKGBUILD to suit your need, you can send the it here and I (or maybe someone else) will try to help you with that.

i posted the solution i use for my AUR/internal packages awhile back, with the intention of suggesting it as a standardized way to handle this use case:

http://mailman.archlinux.org/pipermail/arch-general/2011-July/021078.html

... not all that long of a thread ;-), but i'll highlight a few key benefits over locally storing repositories [in build dir], or other ad hoc solutions:

) uses a targeted fetch instead of a naive clone (for kernel IIRC you get ~50% size reduction, something like ~180MB) ) stores repositories in a known list of locations, with predictable ordering (allows for reuse between package variants) ) generates a lightweight proxy in the event a repository is found but it is read-only (allows for safe use concurrently or within a chroot [mkchrootpkg])

... this doesn't stop emacs/etc from needing a fresh rebuild each time, but the repo will forever be intact until removed (it was unclear if the OP used `rebuild` in the sense of the software [make] or the repo [clone])

you'd need to add the routines to the target package (they are at the end of the link i provided).  this package:

http://aur.archlinux.org/packages/py/pyjamas-engine-pythonwebkit/PKGBUILD

... makes use of them, and serves as an example.  it's not quite as "simple" or "KISS" as some may prefer, but hey, features/flexibility don't always agree with simplicity ... it's not complicated, but it's not a one-liner either.  in the end it saves me a whole 'lotta time, and frankly, what else really matters?

... ah forgot to mention one other thing i found to be useful; said routines introduce the concept of a `_gitspec` variable -- this var falls back to `_gitname` (the branch to be checked out) if missing, and is used when the working directory is being updated: git --git-dir="${g}" --work-tree="${w}" read-tree --reset -u "${_gitspec:-${_gitname}}" ... setting it allows you build any arbitrary revision (must exist on the branch your targeting -- targeted fetch means you don't have the whole repo, only the specific branch you need). i've used this to quickly rebuild stuff when HEAD turned out to be busted, bisecting for bugs, etc. -- C Anthony

On Mon, Sep 19, 2011 at 6:20 PM, Auguste Pop wrote:

yaourt has an option to compile vcs packages in a separate directory rather than the default /tmp directory. in this way, the download part in every recompile can be minimized. just fyi.

btw I added exactly this functionality to packer. cheers! mar77i

On Mon, Sep 19, 2011 at 12:59 PM, solsTiCe d'Hiver wrote:

Note, as emacs might be written in something else than C or C++ like some sort of lisp that might not work. or may be , it could work; I don't know emacs. Vim rocks \o/

Emacs core, which is a lisp interpreter, is written in C.