Alessio 'mOLOk' Bolognino wrote:
<snip>
>> build("mysql") {
>>
>> files("docs") {
>> #will create a foo-mysql-docs-ver-rel.pkg.tar.gz
>> }
>>
>> #all unspecified files here will be put together
>> # into foo-mysql-ver-rel.pkg.tar.gz
>> }
>>
>>
>>
>> Note that both the build() and files() sections can have a local desc=
>> (or pkgdesc=?) that it can optionally inherit from its parent.
>>
>> This is my first draft, which is actually gotten from writting too many
>> RPM spec files, not liking them, wishing they were more like PKGBUILDs
>> and wishing PKGBUILDs would pick one or two good things from them spec
>> files.
>
> PKGBUILDs are bash scripts, what does build("mysql") mean in bash
> scripting?
PKGBUILDs don't _have_ to remain bash scripts... as long as we don't
expect users to do a ./PKGBUILD just to build a package.
One of the things i've learnt is that the _user_ interface should be
allowed to be awkward, just to keep the implementors work down to a
minimum. Also parsing of simple formats like this are actually a plus
(depends on who's thinking of it though). I think, if we keep limiting
it to bash scripting idioms we'll be neglecting the reality infront of
us which is that a PKGBUILD is _not_ _actually_ a bash script, its a
_makepkg_ script :)
Anyways... like I said earlier... both methods actually work for me, my
reservation is just a knee jerk from years of defining software
interface specs for other developers to use :)
cheers,
Essien
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> arch mailing list
> [email protected]
> http://archlinux.org/mailman/listinfo/arch
_______________________________________________
arch mailing list
[email protected]
http://archlinux.org/mailman/listinfo/arch
