[pacman-dev] Comments with `)' are either broken or disallowed

[Dave Reisner]

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