Thanks for bringing this to our attention and working on the feature! 🤗

I find the double occurance of filelist=('*') a bit irritating due to the implicit ordering dependency, but I guess this could have alternatively also been the following which is the style I'd prefer for actual packages:

package_foo() {
    filelist=('*'
              '!usr/share/docs/')
    ...
}

package_foo-docs() {
    filelist=('usr/share/docs/')
    ...
}

Also I quite like the general concept, but find the name "stash" for the pre-package directory suboptimal or atleast something that does not feel natural (as always, naming things is hard). So far I couldn't come up with better names, but thought I'd still note it.

find the name "stash" for the pre-package directory suboptimal

I initially named it install(). I'm sure you can see the problem...

Thanks for the work, this is an interesting idea!
I personally like this approach and would be up to adopt it for the split packages I maintain :)

To relay what was said in IRC already, this would allow to drop the custom _pick / _install function people have been using as a workaround until then.

Note files are removed from the stash as they are included in packages.

Just a quick note: There are some edgy / rare cases where the same file(s) is included in multiple packages within a split package. For instance, when building multiple "version" of the same package that conflict each other (e.g. like this) or when shipping a "general" documentation file accros multiple packages (e.g. under /usr/share/doc/package_{foo,bar}/README.md). In such cases, that would require an additional step of copying said file(s) under a different name / location within $stashdir during stash(), to ensure it can be shipped multiple times accros multiple packages.
Again, this is just a quick note though. As I said, those are edgy / rare cases and I think removing files from the stash as they are included in packages is indeed the way to go. Alternatively, one could still use the current approach instead if required.

I try to avoid using pick() functions (and splitting) and use an alternative approach.

In main package_foo() I mv files from $pkdir to folders in $srcdir & in package_foo1() I then copy the files to $pkdir for foo1 .

The approach outlined here feels like an improved version of that method .

+1

Standardizing the functionality inside makepkg makes a lot of sense.

The current splitting approach leads to monstrosities like the Arch Linux gcc PKGBUILD [1] (of which I completely blame the current packagers and take no responsibility!).

That gave me a loud chuckle 😄

BTW, a while back I did actually convert the gcc PKGBUILD to _pick style.. lucky I never submitted it, ay?

Sidenote: package splitting causes makepkg to suffer from diabolical performance problems. For example:

$ git clone https://gitlab.archlinux.org/archlinux/packaging/packages/qemu.git
$ cd qemu
$ makepkg -g

or for something slightly less painful.. try libblockdev.

@toolybird - using MAKEPKG_LINT_PKGBUILD=0 will remove the checks makepkg runs on the PKGBUILD which causes these slowdowns. Running makepkg -g on qemu goes from 38.9 seconds to 0.45 seconds! There are things I can do about that when the motivation hits me...

Edit - at least it is linear in the number of packages...

As I said on IRC, I think this is a great feature addition, thanks for working on it! I believe a lot of improvements could be achieved by splitting more packages, in an Arch-pragmatic way, to avoid unnecessarily large dependency trees and to reduce the prevalence of optional dependencies.

I contrast to some opinions I quite like the name stash. I think it's intuitive in the sense of that we "stash" our files before we go on to create the packages from those files.

Do you have a specific pattern format in mind? The format shown here reminds me of the gitignore pattern format.

As an exercise, below are the current ghc package functions written in the new format:

package_ghc_static() {
    filelist=('usr/lib/**/*.a' 'usr/lib/**/*.o' 'usr/lib/**/*.p_o' 'usr/lib/**/*.p_hi' 'usr/lib/**/*.hi'
              "usr/lib/ghc-$pkgver/lib/static-package.conf.d"
              'usr/share/doc/'
              'usr/share/libalpm/hooks/ghc-rebuild-doc-index.hook')
    ...
}
package_ghc() {
    filelist=('usr/bin'
              '!usr/bin/ghc-pkg*'
              "usr/lib/ghc-$pkgver"
              "!usr/lib/ghc-$pkgver/bin/ghc-pkg*"
              "!usr/lib/ghc-$pkgver/lib/package.conf.d"
              "!usr/lib/ghc-$pkgver/lib/static-package.conf.d"
              "!usr/lib/ghc-$pkgver/lib/$CARCH-linux-ghc-$pkgver/"
              "usr/lib/ghc-$pkgver/lib/$CARCH-linux-ghc-$pkgver/ghc-$pkgver"
              "usr/lib/ghc-$pkgver/lib/$CARCH-linux-ghc-$pkgver/libHSghc-$pkgver-ghc$pkgver.so"
              'usr/include/'
              'usr/share/bash-completion/'
              'usr/share/man/'
              '!usr/lib/**/*.a' '!usr/lib/**/*.o' '!usr/lib/**/*.p_o' '!usr/lib/**/*.p_hi' '!usr/lib/**/*.hi')
    ...
}
package_ghc_libs() {
    filelist=('usr/bin/ghc-pkg*'
              "usr/lib/ghc-$pkgver/lib/$CARCH-linux-ghc-$pkgver/"
              "!usr/lib/ghc-$pkgver/lib/$CARCH-linux-ghc-$pkgver/ghc-$pkgver"
              "!usr/lib/ghc-$pkgver/lib/$CARCH-linux-ghc-$pkgver/libHSghc-$pkgver-ghc$pkgver.so"
              "usr/lib/ghc-$pkgver/bin/ghc-pkg*"
              "usr/lib/ghc-$pkgver/lib/package.conf.d"
              'usr/share/haskell/'
              'usr/share/licenses/'
              'usr/share/libalpm/hooks/ghc-register.hook'
              'usr/share/libalpm/hooks/ghc-unregister.hook'
              '!usr/lib/**/*.a' '!usr/lib/**/*.o' '!usr/lib/**/*.p_o' '!usr/lib/**/*.p_hi' '!usr/lib/**/*.hi')
    ...
}

Just for visualisation, the stash function would have to do the heavy lifting to get the files in order. But I don't find it half bad.

All the globs get translated to a find command, so I doubt ** will be supported.

I'd translate <prefix>/**/<expr> into

find "$stashdir"/<prefix> \( -name <expr> \) -type f -exec mv {} "$pkgdir"/

We'd have to document that only file globs are allowed in <expr> (i.e. no path separator allowed). I guess that's fine, though perhaps counterintuitive if one expects the full gitignore functionality. Then again, an error is easily produced to inform people.

Would that be enough to add support for this behaviour? As shown above, ghc could make use of it.