Put them as make and optional deps :-)

Then the way to go is to make a separate package for each. Liba-pytgon liba-perl...

On 17 May 2011 05:20, Michael Schubert wrote:

2011/5/16 jesse jaara

...

Put them as make and optional deps :-)

But make doesn't depend on them. Also, I wouldn't want to install <some weird programming language> in order to get the package to build.

That's the way it's done. You have those optdeps as makedeps so you can finish building the package. These deps will be installed as deps, so a -Qdt would show them as orphans. There is --rmdeps that takes care of this; makepkg -sr. -- GPG/PGP ID: 8AADBB10

On 17 May 2011 18:14, Michael Schubert wrote:

2011/5/17 Ray Rashif

...

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

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

On 2011-05-18 00:14 +0800 (20:3) Ray Rashif wrote:

...

...

2011/5/17 Ray Rashif

...

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

On 17 May 2011 18:14, Michael Schubert wrote: 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