On Tue, May 13, 2014 at 01:18:33PM +0800, lolilolicon wrote:
On Tue, May 13, 2014 at 1:43 AM, Dave Reisner <d@falconindy.com> 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