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 > arch@archlinux.org > http://archlinux.org/mailman/listinfo/arch _______________________________________________ arch mailing list arch@archlinux.org http://archlinux.org/mailman/listinfo/arch