[pacman-dev] makepkg enhancements: globstar and variable expansions in PURGE_TARGETS, MAN_DIRS, etc.

[Allan McRae]

Ciprian Dorin, Craciun wrote:
>     Hy everybody!
> 
>     While building some custom packages for a stripped down Linux
> server, I've hit the following problems:
>     * the cause of the problems is from the pact that my packages are
> each in it's own folder like: /packages/bash--4.0--1,
> /packages/busybox--1.15.2--1, etc., and thus,
>     * MAN_DIRS, DOC_DIRS, STRIP_DIRS and PRUNE_TARGETS doesn't work,
> as I have no way to use ${pkgname}, etc in there;
>     * in PRUNE_TARGETS there is no way to specify file patterns (like
> '*.a', or '*.la'), but only from certain folders; (for example I can
> say '*.a', but not '../lib/*.a'; also I can not specify unknown number
> of parents, like '.../lib/**/*.a';
> 
>     As a consequence, I propose (and if accepted I also have the
> patches for) the following enhancements:
>     * allow the patterns in MAN_DIRS, etc. to be evaluated at the
> proper time execution time (when we access MAN_DIRS), not at
> configuration time (when we define MAN_DIRS); this can be achieved by
> (single) quoting the patterns like:
> 'package/${pkgname}--${pkgver}--${pkgrel}/{,share/}man' and then
> expansion by using eval;

You can use

MAN_DIRS=({package/*/,}{usr{,/local}{,/share},opt/*}/{man,info})

and that will work.  An eval statement is evil.


>     * allow enhanced pattern types for PURGE_TARGETS, like:
>         * the same lazy evaluation as above;
>         * if a pattern starts with '=' then it must exactly match a file name;
>         * if a pattern starts with '+' then it is a glob pattern (or
> globstar), like:
> 'packages/${pkgname}--${pkgver}--${pkgrel}/lib/**/*.a'

These seem to be able to be handled in much the same way as MAN_DIRS above.

>         * if a pattern ends with '/' then we use `rm -Rf`, else we use `rm -f`

Instead of ending in /, end it in /* and combine with !emptydirs?

>         * maybe if a pattern starts with '@' then it is a regular
> expression, etc. (this I have not implemented);
> 
>     Any comments?

This all sounds overcomplicated.  Before considering this further, I 
would like to see an example that can not be handled by the current setup.

Allan