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...
Allan
_______________________________________________
arch mailing list
[email protected]
http://archlinux.org/mailman/listinfo/arch
