colord recently took an unconditional dependency on udev, meaning that it can no longer be built on (for example) FreeBSD. https://github.com/hughsie/colord/commit/b306809d2a789bb87020f2a871ea96e2c0ce017b The patch looks fairly casual about the addition of the configure check. Was this intentional?
Hey, It was fairly casual, but I'm more than happy for a freebsd person to add the required code to make it work again. I have no idea how to use freebsd and so no way to test. Without the hwdb, the EDID functionality will just fail, so there would need to be somekind of alternate lookup there, so it's more involved than just sprinkling a few #ifdefs around. Richard
commit 9a13abb3ed8aef32287d1f628c01c0a886615038 Author: Richard Hughes <richard@hughsie.com> Date: Tue Dec 10 15:20:16 2013 +0000 Fall back to parsing pnp.ids if udev is not available :100644 100644 1932304... b3d33fa... M lib/colord/cd-edid.c
Not quite fixed yet, unfortunately. There is still an unconditional dependency on udev in the pkg-config of colord, even if it was built without udev support. I'm not sure why that is -- no public headers in colord include udev headers so it's not needed for that and as far as linking, libcolord's .so file contains the necessary information. I think it can just be removed...
So it exists for static libraries...
I guess we have to process the Requires.private with some sed magic.
commit 9aa0943ef8f1601202bc1f0baafd0bb49ed41263 Author: Richard Hughes <richard@hughsie.com> Date: Mon Dec 16 13:24:32 2013 +0000 Only include libudev in Requires.private on Linux Resolves: https://bugs.freedesktop.org/show_bug.cgi?id=72539
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.