libgpiod: Make Python bindings optional

[ernestask]

📦 Package Details

Maintainer: @mhei

Description:
python3-gpiod causes python3-light to be built even if not selected, which can be avoided by making the dependency conditional`.

How to test:

1. Select gpiod-tools
2. make package/libgpiod/compile

Without the changes: python3 (and bluez) get built as dependencies
With the changes: python3 is not built

---

🧪 Run Testing Details

• OpenWrt Version: 9247eb400241cd2b6f3ec141744b560dcf59c8db
• OpenWrt Target/Subtarget: mediatek/filogic
• OpenWrt Device: openwrt-one

---

✅ Formalities

• I have reviewed the CONTRIBUTING.md file for detailed contributing guidelines.

[pprindeville]

Nix on the isc-dhcp changes.

[pprindeville]

I don't get this. Look at the install directions for this package. It doesn't do anything but make sure dependencies are satisfied. It's a meta-package. Making the dependencies conditional would defeat the purpose of having it.

[ernestask]

The install section is irrelevant here, but perhaps I haven’t expressed myself properly, so let me try to explain my problem again

scripts/package-metadata.pl will parse the package and spit out a line like this to tmp/.packagedeps (which is then used for ordering builds):

$(curdir)/feeds/packages/isc-dhcp/compile += $(curdir)/feeds/packages/bind/compile $(curdir)/libs/toolchain/compile $(curdir)/libs/zlib/compile

That means that if I select, say PACKAGE_isc-dhcp-relay-ipv6, in my config and leave PACKAGE_isc-dhcp-dyndns unselected, bind will still be built as a build dependency.

With the change, it would look more like this:

$(curdir)/feeds/packages/isc-dhcp/compile += $(curdir)/libs/toolchain/compile $(curdir)/libs/zlib/compile $(if $(CONFIG_PACKAGE_isc-dhcp-dyndns),$(curdir)/feeds/packages/bind/compile)

…and my build times would become ever-so-slightly shorter (the worse offender in my case is libgpiod with Python).

[ernestask]

An existing example: 0c245fd

[pprindeville]

Still not getting it. All of this is inside the definition of the subpackage isc-dhcp-dyndns so why would any of it take effect if that package isn't already selected? Isn't what you're doing redundant?

[ernestask]

Due to how the package scripts work overall, it’s not redundant, unfortunately. All of the (sub-)package dependencies within a Makefile are collected and become implicit build dependencies, whether a particular subpackage is enabled or not (just picking any one is enough, because they are per-directory).

It could be “fixed” (it’s not a bug per se, more a build time optimization) by doing the same for all packages by default, but quite a few packages unknowingly rely on implicit behavior and would need fixing to get dependencies right, so I’m cherry-picking individual package changes I made.

It’s pretty much only noticable when building n+1 times a day and looking at the make output.

[mhei]

The libgpiod changes LGTM for a first quick look, will have a deeper one today evening or tomorrow.

[mhei]

This part does not work well: the python bindings are disabled by default and there is no auto-magic to enable them. On the other hand, passing --enable-bindings-python does not work for me in my local build: the build pulls in host python and fails to build. This is why the whole python build magic is wrapped later with Py3Package,python3-gpiod which sets the correct build environment (but it is not set already during "normal" package build).
I think you should drop this chunk.

[ernestask]

Dropped.