[pacman-dev] makepkg patch - simple pkg class feature

[K. Piche]

On Wed, 2008-01-09 at 22:33 -0600, Dan McGee wrote:
> On Jan 9, 2008 10:10 PM, K. Piche <kpiche at rogers.com> wrote:
> >
> >
> > On Tue, 2008-01-08 at 17:44 -0600, Dan McGee wrote:
> > > On Jan 8, 2008 5:28 PM, Roman Kyrylych <roman.kyrylych at gmail.com> wrote:
> > > > 2007/12/27, K. Piche <kpiche at rogers.com>:
> > > >
> > > > > Hi,
> > > > >
> > > > > I hope everyone had a great holiday!
> > > > >
> > > > > Perl module PKGBUILDs tend to be a mess and some build() functions are
> > > > > not "standard".  Now with the new upcoming perl policy all of the
> > > > > PKGBUILDs need to be "standardized" again.  To help combat this problem
> > > > > I hacked up a package class feature where all the functions and package
> > > > > defaults are set in a class file and sourced before the package is
> > > > > built.  The class file can define a set of build functions to call
> > > > > instead of just build().
> > > > >
> > > > > Some advantages:
> > > > > - standardization of package types, even AUR packages could be uniform
> > > > > - code in makepkg could be moved to a class so that it could easily be
> > > > > override by people doing non-standard things: no man pages, i585 ports
> > > > > - anything set in the PKGBUILD takes precedence over the class
> > > > > - defined build functions can be optional (see the sample perl class)
> > > > >
> > > > > The patch is backwards compatible with non-class PKGBUILDs and I have
> > > > > been using my classy makepkg for 5 days.
> > > > >
> > > > > Attached is the patch, a perl class, and sample PKGBUILD for
> > > > > Sys::Syslog.  Right now the class file has to be in the same directory
> > > > > as the PKGBUILD.
> > > > >
> > > > > Happy New Year!
> > > > >
> > > >
> > > > Dan, Aaron, is this in your working trees somewhere?
> > > > Otherwise it would be better to create a feature request on Flyspray
> > > > so it won't get lost.
> > >
> > > Sorry that I haven't responded. At first glance, I like this idea. I
> > > want to queue it up for 3.2 after some discussion and looking at it if
> > > no one else objects. I've just been a bit busy worrying about release
> > > fixes so I haven't had time to review this.
> >
> > That's why I didn't ask...  :)
> 
> 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.

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.


> Kevin, what do you think? Naming kinks would need to be worked out
> (buildlib, a *.build convention, etc) but I think this is a good idea
> to run with.
> 
> I'd also like to see the ability to have buildlib's be located both
> locally and somewhere like /usr/share/makepkg/svn.build.
> 
> -Dan
> 
> _______________________________________________
> pacman-dev mailing list
> pacman-dev at archlinux.org
> http://archlinux.org/mailman/listinfo/pacman-dev
-- 
K. Piche <kpiche at rogers.com>