[pacman-dev] inside PKGBUILD customizable makepkg PURGE_TARGETS

[Allan McRae]

Ciprian Dorin, Craciun wrote:
> On Thu, Dec 3, 2009 at 2:39 AM, Dan McGee <dpmcgee at gmail.com> wrote:
>> On Wed, Dec 2, 2009 at 3:48 PM, Allan McRae <allan at archlinux.org> wrote:
>>> Ciprian Dorin, Craciun wrote:
>>>>    Hello all!
>>>>
>>>>    Again I have a proposal to enhance makepkg PURGE_TARGETS handling.
>>>>
>>>>    I think that enabling customizing PURGE_TARGETS inside PKGBUILD
>>>> would be a benefit in the following context:
>>> Without checking, I would have thought that exporting "PURGE_TRAGETS=..."
>>> within a package function would just work.  I guess the old value would not
>>> be restored afterwards though.
>> This seems like complete overkill for makepkg to support. I'm -1 on this.
> 
> 
>      What overkill? Really? It's a 3 or 4-line update:
> 
> ~~~~ instead of this:
>         if [ "$(check_option purge)" = "y" -a -n "${PURGE_TARGETS[*]}" ]; then
>                 msg2 "$(gettext "Purging other files...")"
> ~~~~ we'll have this:
> +        local purge_targets=( "${pkg_purge_targets[@]:-${PURGE_TARGETS[@]}}" )
> +        eval 'purge_targets=(
> "${'"${pkgname}"'_purge_targets[@]:-${purge_targets[@]}" )'
> +        if [ "$(check_option purge)" = "y" -a -n "${purge_targets[*]}" ]; then
>  -       if [ "$(check_option purge)" = "y" -a -n "${PURGE_TARGETS[*]}" ]; then
>                 msg2 "$(gettext "Purging other files...")"
> ~~~~ and we have to replace `PURGE_TARGETS` with `purge_targets`
> somewhare below in 2 places.
> 

As I said, defining PURGE_TARGETS in a package_foo() function already works:

e.g.

package_t1() {
   PURGE_TARGETS=(*.a)
   touch $pkgdir/foo.a
   touch $pkgdir/foo.doc
}

package_t2() {
   PURGE_TARGETS=(*.doc)
   touch $pkgdir/foo.a
   touch $pkgdir/foo.doc
}

Guess which file ends up in which package...

> 
>     Guys, as developers of makepkg, you really have something against
> extensions that would allow writing simpler or more versatile
> PKGBUILD's...

No, we just do not believe any of the ideas you have shown us so far are 
making simpler PKGBUILDs or achieving something that can not already be 
done with makepkg using the same number of lines in the PKGBUILD

>     For example, below is one of my PKGBUILDS, that uses what I call a
> "template", which allows me to abstract away patching, calling
> configure, and make. And in order to support this split of packages,
> all I have to do is update my `configure+make+make-install` script to
> understand this, and just put `pkgname=( isync-bin isync-doc )`.
> (Unfortunately this doesn't have a lib or dev).
> 
>     My `configure+make+make-install` just implements `build` and
> `package` functions that use the variables defined in the PKGBUILD,
> with some sensible defaults. (I think this resembles somehow GoboLinux
> recipies...)
> 
> ~~~~
> . "${pkgbuild_tools_root}/configure+make+make-install"
> 
> pkgname=( isync )
> _pkgver=1.0.4
> _pkgpatch=+1
> pkgver="${_pkgver}${_pkgpatch}"
> pkgrel=1
> 
> depends=()
> makedepends=(
> 		openssl db
> 		gcc binutils glibc
> 		make coreutils bash
> 		sed grep patch
> )
> 
> _declare_arch
> _declare_paths
> _declare_build_environment
> _declare_configure_options
> 
> _configure_options=(
> 		"${_configure_options[@]}"
> 		--disable-compat
> )
> 
> _LIBS=(
> 		"${_LIBS[@]}"
> 		-static
> 		-ldb -lpthread
> )
> 
> _src_patches=(
> 		imap_recursive_maildir.patch
> 		imap_certificate_ignore.patch
> )
> 
> source=(
> 		"http://switch.dl.sourceforge.net/project/isync/isync/${_pkgver}/isync-${_pkgver}.tar.gz"
> 		imap_recursive_maildir.patch
> 		imap_certificate_ignore.patch
> )
> md5sums=(
> 		8a836a6f4b43cd38a8b8153048417616
> 		fd42b61f2979d2bf2d08f1528a292ec5
> 		efbe84127425024676b07c2fdef87a98
> )

I would not call that simpler.  I look at that and have only vague ideas 
what the packaging would be doing, whereas a normal package I see the 
exact commands.

Allan