Jaroslaw Swierczynski wrote:
> How about this:
>
> pkgname=gcc
> pkgver=4.2.1
> pkgrel=5
> pkgdesc="The GNU Compiler Collection"
> pkgsub=(libs)
> pkgdesc_libs="Runtime libraries shipped by GCC for C and C++ languages"
> depends=(binutils gcc-libs)
> depends_libs=(glibc)
>
> build() {
> cd "$startdir/src/$pkgname-$pkgver"
>
> ./configure --prefix=/usr
> make || return 1
> make DESTDIR="$startdir/pkg" install
> }
>
> build_libs() {
> install -m 644 something $startdig/pkg-libs
> }
this also works, build("libs") just feels cleaner than build_libs()
truth is both work and are basically the same thing. :) (I actually have
this knee jerk reaction to interfaces definitions that depend on
nomenclature...)
>
The only thing this approach takes for granted is that build_libs() will
_always_ have the same _config_ and _build_ options as the main build
sections. So as I see it, there are two possible reasons to have sub
packages. 1) Different Build options (which is not addressed). 2) Funky
File packaging requirements (which this approach takes care of).
As an added bonus, combining/nesting the two approaches should be possible.
Another key thing is to make it possible to inherit properties like
pkgdesc, pkgdepends, etc, since the libs package would need to have at
the minimum a different description than the main package.
_______________________________________________
arch mailing list
arch@archlinux.org
http://archlinux.org/mailman/listinfo/arch
