>> 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") wouild
>> 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
sounds interesting... very. Can you give s snippet from the resuling
PKGBUILD? sorry i'm a bit slow with _only_ textual descriptions :)
sounds simple to avoid the problems with the custom parser too.
cheers,
Essien
>>
>>
>>
>> _______________________________________________
>> arch mailing list
>> [email protected]
>> http://archlinux.org/mailman/listinfo/arch
>
> _______________________________________________
> arch mailing list
> [email protected]
> http://archlinux.org/mailman/listinfo/arch
>
_______________________________________________
arch mailing list
[email protected]
http://archlinux.org/mailman/listinfo/arch
