Thank you Xyne and others, that was very helpful. I'm going to build standard bindings (Perl, Python) and add commented lines for the other ones.
Michael 2011/5/18 Xyne <[email protected]> > On 2011-05-18 00:14 +0800 (20:3) > Ray Rashif wrote: > > > On 17 May 2011 18:14, Michael Schubert <[email protected]> wrote: > > > 2011/5/17 Ray Rashif <[email protected]> > > > > > >> > > >> That's the way it's done. You have those optdeps as makedeps so you > > >> can finish building the package. > > >> > > > > > > Sorry if I was a bit unclear earlier. The make process does not need > all > > > binding languages as dependencies as cmake and configure take care of > > > preventing those from being built. So the make works fine with no > optional > > > dependencies installed. > > > > When you're distributing any modular package that, when installed with > > all usable dependencies, would provide full software functionality, > > someone (the builder/packager) has to initially configure and build > > the software with everything in place. > > > > * So, you first install all usable deps, build it, then remove the > > unimportant deps (thus making them makedeps + optdeps). > > > > If a dep cannot be removed (when a particular part of the software > > complains about something missing or does not work as expected), then > > it cannot be an optional dependency. Sometimes, in order to appease > > everyone, you must build and depend on deps that not everyone would > > need, because those deps are link-level or hardcoded once used (to > > build). > > . > > You don't have to build multiple packages just because of this, unless > > we're talking about a rather large software compilation/bundle. > > > > But yes, you may split the package in the end. If it is easier for you > > then build as many times within the PKGBUILD as needed, to for example > > a different directory each time. Then you can package separately and > > the result is a split package. Do this only if building in the > > optional support actually leads to unwanted bulk for those not needing > > the optional functionality. > > > > > > -- > > GPG/PGP ID: 8AADBB10 > > Rephrasing and adding to what's already been said, the ideal would be to > provide separate *non-mutually-exclusive* packages for each binding > (python-foo, perl-foo, etc). That would let each user install exactly what > they > want. > > If that is not possible, then build the package with support for the > default > bindings, or whichever bindings are most common across distros if there are > no > official defaults. If binding support for foo requires that foo be > installed *at > runtime* (i.e. the package will display warnings and or not run without > foo), > then make foo a dependency (depends) of the package. If binding support > only > requires that foo be present at build time, make foo a build dependency > (makedepends) and an optional dependency (optdepends). > > Users who wish to add or remove binding support not provided by the default > package can simply edit the PKGBUILD and build a customized version. To > facilitate this, split the build options across different lines in the > PKGBUILD > and comment the non-default bindings so other users can easily modify them. > Add > a few comments to remind users about updating the depends, makedepends and > optdepends arrays when necessary. > > Regards, > Xyne > >
