On 10/01/2010, at 4:23, Xyne <x...@archlinux.ca> wrote:

It is quite a clever idea. I haven't seen this approach before. I
haven't looked at it thoroughly, but it looks like you're simply
sourcing the PKGBUILD with some trickery not to execute the code. Why
then the need for further parsing? Does `set` produce "raw" bash, e.g. 'source=("https://localhost/$pkgname.tgz";)'? It seems like bash should
be able to do it itself. If that were the case, the parser would be
extremely reliable (definitely more so than mine). There are still
some "safety" issues involved, although maybe not for your purposes.
One major thing is infinite loops - there's no way to break them. I'm
sure this parser will be very useful when such things aren't an issue.
Bash simply parses the file and stores the code itself in the
"pkgbuild" function, which itself contains other variables and
functions (e.g. package_foo, build). Because the code has not been
executed, the variables have not been expanded/interpolated and thus
still contain things such s "http://example.com/$pkgname-$pkgver.tar";,
which is why it must still be intepolated by the parser.

It seems I did understand it, I just forgot assignments don't get interpreted. I suppose there's no way to get bash to execute the assignments but not the code? Perhaps filtering the function definitions from set output. I havn't looked at the output of set so, again, I'm shooting in the dark here.


The advantage of this method is that "set" will print out the
"pkgbuild" function and its contents in a canonical form, e.g. all
assignments to a variable are on a single line, if/then/else statements
follow a single format, etc.

That is very handy indeed.

Let me repeat that my method does not run any code in the
PKGBUILD. I've tested this by including an infinite loop at the top of
the file and it was not executed. I actually believe that this method
provides a perfectly safe and potentially very reliable method of
retrieving all metadata in the PKGBUILD with very little dependencies
and considerable portability.

Indeed. Perhaps Allan would be interested on this for his makepkg test suite, although maybe more in the concept since the test suite us in python.



Regards,
Xyne

Reply via email to