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! :-)
--
Roman Kyrylych (Роман Кирилич)
_______________________________________________
arch mailing list
arch@archlinux.org
http://archlinux.org/mailman/listinfo/arch
