On Jan 13, 2008 7:23 PM, K. Piche <kpiche@rogers.com> wrote:
On Wed, 2008-01-09 at 22:33 -0600, Dan McGee wrote:
OK, now that the release is out the door (a whole hour ago :P), I'll take a look.
I've been thinking of something like this for a while, because this kind of thing would be mucho-handy for SVN/GIT/etc. PKGBUILDs as well.
How about something more like this?
pkgname=foobar pkgver=1.0 pkgrel=1 ....... buildlib=perl.build install=foobar.install
build() { pre_build() perl_build() post_build() }
perl.build would be sourced before the build() function is called, so those functions (and variable redefinitions) would be available. Hell, you could probably even define build() in there as long as we set it up right.
This would allow a bit more flexibility than what your patch afforded in that you could mix function calls with the ability to still tweak the build in build().
I'm not really sure there is a difference. Your build calls the functions to run but that is equivalent to the array build_funcs="pre_build perl_build post_build". It's just syntax.
What I liked about my setup is that I could build a perl module with 6 or 7 variables and no build() in the PKGBUILD.
And this is what I was trying to stay away from. I hate looking at Gentoo emerge files (what are they called?), and I've never been a fan of the huge abstraction that Frugalware uses in their PKGBUILD files. The whole idea of a PKGBUILD in my eyes is ease of use- if a user wants to customize it, everything is *right there* in front of them. They don't have to fight to add or remove a single configure flag, or get docs installed, etc.
I also figured that the "optional" build functions would allow for interesting possibilities - define a build_funcs="patch configure compile install extras". If a source distribution was standard no build() would be required but the parts of a standard build could be changed:
pkgname=blah ... patch() { patch -Np0 -i fixit.patch } EOF
The local patch func would be used and the standard compile, install, etc would come from the class. If a PKGBUILD had no patch() and there wasn't one in the class it would simply be skipped.
People switch to Arch, like what they see, and then attempt to build their first package. A proficient Linux user can have one written in 10 minutes. I don't want anything to take that ease of use away, that's all. And I know users wouldn't be required to use this, but I'm sure they would want to customize a PKGBUILD that did and explaining to a user why a build function is optional just seems to be too much for me. -Dan