On 9/27/07, Roman Kyrylych <[EMAIL PROTECTED]> wrote:
> 2007/9/27, Allan McRae <[EMAIL PROTECTED]>:
> > I have been thinking about how this should be done without creating a
> > custom parser for the last few days.
> >
> > What I see is two cases for the use of split packages
> > 1) Splitting build output - e.g. gcc and gcc-libs
> > 2) Allowing the same package to be built with different configuration
> > options. e.g ettercap and ettercap-gtk
> >
> >
> > For 1), how about adding a package() function but only if needed. I.e.
> > most of the time the moving of files occurs as usual in the build()
> > function and no package function would be used. If there is a package
> > function present, then the makepkg will know we a packaging two (or
> > more) packages at once. The naming could be automatically done by using
> > and extra directory level.
> >
> > E.g for gcc we could have the package function move files into :
> >
> > pkg/main
> > pkg/libs
> > pkg/fortran
> > pkg/objc
> >
> > makepkg would recognize pkg/main as the primary package and create
> > gcc-4.1.2-2-i686.pkg.tar.gz. The other directories would have their
> > names based on the folder. I.e the files in libs would become
> > gcc-libs-4.1.2-2-i686.pkg.tar.gz.
> >
> >
> > For 2), the whole package would require a rebuild anyway. So how about
> > using command line arguments.
> >
> > E.g. for ettercap we could have "makepkg" make the default (ncurses)
> > interface and "makepkg gtk" make the gtk interface. The package naming
> > would just have the command line parameter added.
> >
> > E.g for packages with no sensible default (e.g. configuring using mysql
> > instead of postgres) "makepkg" would print an error message and "makepkg
> > foo" would build the appropriate package.
> >
> > In bash, this could be easily implemented using if/case statements.
> >
> >
> > The points I like about this idea are
> > a) It requires no custom parser like using build("foo") would
> > b) It involves only adding 1 extra function to split packages anyway.
> > I.e. makepkg does not have to deal with many build_libs, build_docs,
> > build_foo function names.
> > c) when no package function or command line options is specified,
> > current package builds will still work.
> > d) I don't think it would be too hard to implement
> >
> >
> > Let me know if I haven't expressed my ideas clearly enough...
> >
>
> You won the "Best idea in the whole thread" prize from me! :-)
I have to agree with Roman here. Not only did you stay on topic (/me
glares at the above messages), but this actually solves MULTIPLE
problems.
There was a request a while ago, to convert the "build" functions into
one or two functions (only used if present, of course). The problem is
that some packages have a long build time, but the PKGBUILD error may
have been after the 'make'. So we'd want to re-run just the stuff
after the build.
I need to think about this, but I like this better than most ideas.
Could you possibly file a Feature Request in flyspray regarding this,
so we can have it on record?
Thanks,
Aaron
_______________________________________________
arch mailing list
arch@archlinux.org
http://archlinux.org/mailman/listinfo/arch
