On Tue, May 13, 2014 at 01:18:33PM +0800, lolilolicon wrote: > On Tue, May 13, 2014 at 1:43 AM, Dave Reisner <[email protected]> wrote: > > On Mon, May 12, 2014 at 01:06:20PM +0800, lolilolicon wrote: > >> > >> These are in the check_sanity function, by the time which is run we > >> already source'd the BUILDFILE, correct? Why don't we use the existing > >> variable arrays then? > >> > > > > You're forgetting about package-level overrides, which aren't available > > in the environment. > > Alright, we're cursed, aren't we? Gone are dreams of grace and order, > now we must indulge in patch and scratch.
Well, I'd like to think there's a slightly better tomorrow out there, but I'm largely biased: https://github.com/falconindy/pkgbuild-introspection Not yet mature enough for makepkg, IMO, but it'll be powering AUR 3.0's enhanced metadata. > Anyway, maybe we can ask bash to pre-formalize the PKGBUILD a little > bit so be can parse it more confidently com, by using abination of > `set -x` and `typeset`. For example, consider the following > troublesome PKGBUILD: > > foo=(a \ > b # ) > 'c: )' > ) > > package_one() { > foo=(d > 'e: 4 #1') > } > > package_two() { > foo+=(z) > } > > We can append to the end of it: > > typeset -f package_one package_two Well, no one these days should be using typeset. Always use declare. > > And then if you execute it with: PS4='' bash -x ./PKGBUILD, the output > is formalized, with comments stripped too: > > foo=(a b 'c: )') > typeset -f package_one package_two > package_one () > { > foo=(d 'e: 4 #1') > } > package_two () > { > foo+=(z) > } > > What do you think? > Sure, we do this elsewhere in makepkg. I'm not clear on why this can't also apply to check_sanity since, as you point out, we've already sourced the build file by the time this runs. d
