On Wed, Mar 30, 2005 at 06:53:42PM +0100, Oliver Burnett-Hall wrote:
> On Wed, 2005-03-30 at 15:20 +0200, Tobias Kieslich wrote:
> > On Wed, 30 Mar 2005 13:57:37 +0200
> > J�rgen H�tzel <[EMAIL PROTECTED]> wrote:
> > > Wouldn't it be nice to predefine the build function. Many packages
> > > just copy the predefined build function. This would reduce code
> > > duplication. Here's a patch. 
> > > 
> > > The gentoo guys also split the packaging process into 
> > > src_{unpack,compile,install}. When the build function in arch is
> > > splited up and predefined this could allow further reduction of code
> > > duplication.
> > > 
> > There are also a lot of packages that, not only copy the generic function -
> > instead they sed/patch code, source config files, export paths etc.
> > 
> > To introduce predefined functions would produce some kind of our own
> > scripting (wrapper) language where bash/shell does the job much better,
> > since you will to have define new subroutines for the tweaks. Or you mix
> > up your own function with shell commands, and this is IMHO very "dirty"
> 
> I think you've misunderstood the proposal/patch; all it means is that if
> the pkgbuild script doesn't define a build() function then the default
> one would be used.
> 
> Personally, I think every pkgbuild script that I've written has had a
> changed build() function, so I'm not sure that this would make much
> difference.
Yes, i just "grep"ed through the PKGBUILDs  and made a "diff -w" against the
build function from PKGBUILD.proto. Only 69 match ;) Some make just
noneffective changes: Using ${pkgname} instead of $pkgname. 
> But I would be in favour of splitting out a lot of the existing makepkg
> script into functions that could be overridden in the pkgbuild script if
> required - being able to replace the default fetch/unpack method would
> be useful.
One thing i like about Gentoo's ebuilds is code reuse. For example all 
python extension  use the "distutils eclass" which is just a library of
shell functions. Well but there is also a trade off: One developer changes
the eclass and some dependent ebuilds are immediately broken ;)  This not a
an uncommon subject on their bugzilla site.
> Maybe I'll write a patch for this next time I need it :)
> 
> - olly
J�rgen

_______________________________________________
arch mailing list
[email protected]
http://www.archlinux.org/mailman/listinfo/arch

Reply via email to