Page MenuHomeFreeBSD

x11/kdelibs4 - honour ZEROCONF port option
ClosedPublic

Authored by alonso on Oct 30 2014, 10:33 PM.
Tags
None
Referenced Files
Unknown Object (File)
Feb 2 2024, 9:48 AM
Unknown Object (File)
Jan 30 2024, 11:16 PM
Unknown Object (File)
Jan 20 2024, 11:23 PM
Unknown Object (File)
Jan 12 2024, 11:15 AM
Unknown Object (File)
Jan 12 2024, 6:23 AM
Unknown Object (File)
Dec 19 2023, 10:07 PM
Unknown Object (File)
Dec 10 2023, 5:06 PM
Unknown Object (File)
Dec 8 2023, 9:14 PM
Subscribers

Details

Reviewers
rakuco
makc
Group Reviewers
kde
Summary

Due to the search order in dnssd/CMakeLists.txt AVAHI was always used if it
could be located on the system. Force cmake to not search for AVAHI/mDNS by
defining KDE's OptionalFindPackage Macros depending on the PORTS switches.

This commit request is taken from area51's revision 10453 and is related to D1021.

Test Plan

Either modify dnssd/CMakeLists.txt to emit MESSAGE()-s logging the branch
conditions or traversed branches, or use ldd to check wether or not
mDNSResponders' libdns_sd.so is referenced by ${PREFIX}/lib/libkdnssd.so of the
built port, which it should be iff kdelibs4's ZEROCONF port option is
MDNSRESPONDER.

Diff Detail

Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

alonso retitled this revision from to x11/kdelibs4 - honour ZEROCONF port option.
alonso updated this object.
alonso edited the test plan for this revision. (Show Details)
alonso added reviewers: rakuco, makc, kde.

Make sure the style of CMAKE_ARGS is consistent with the rest of the file (i.e. replace ON/OFF with On/Off). And don't bump PORTREVISION — there is no need for rebuilding the package.

Make sure the style of CMAKE_ARGS is consistent with the rest of the file (i.e. replace ON/OFF with On/Off).

Plus we tend to group all variables related to an option (so AVAHI_LIB_DEPENDS/AVAHI_CMAKE_* then the corresponding MDNSRESPONDER_* variables).

And don't bump PORTREVISION — there is no need for rebuilding the package.

Are you sure? Looking at kdelibs's dnssd/CMakeLists.txt, we were indeed never building the mDNSResponder backend at all, even with our MDNSRESPONDER option defaulting to on. Since we hard-depend on net/avahi-app, HAVE_AVAHI in CMakeLists.txt was always set and we were always building the Avahi code.

However, taking one step back this also means that we've never built the mDNSResponder backend at all, at least for a long time (this can be partially verified by looking at the beefy{1,2} logs for the port). The detection code in kdelibs was added in 2007, and our dependency on net/avahi-app has always existed (since area51 r3659).

This could very well be an argument in favor of removing the MDNSRESPONDER option altogether (it's not clear to me how it was ever used even though miwi added it as a missing dependency in area51 r3671).

In D1031#4, @rakuco wrote:

Make sure the style of CMAKE_ARGS is consistent with the rest of the file (i.e. replace ON/OFF with On/Off).

Plus we tend to group all variables related to an option (so AVAHI_LIB_DEPENDS/AVAHI_CMAKE_* then the corresponding MDNSRESPONDER_* variables).

And don't bump PORTREVISION — there is no need for rebuilding the package.

Are you sure? Looking at kdelibs's dnssd/CMakeLists.txt, we were indeed never building the mDNSResponder backend at all, even with our MDNSRESPONDER option defaulting to on. Since we hard-depend on net/avahi-app, HAVE_AVAHI in CMakeLists.txt was always set and we were always building the Avahi code.

However, taking one step back this also means that we've never built the mDNSResponder backend at all, at least for a long time (this can be partially verified by looking at the beefy{1,2} logs for the port). The detection code in kdelibs was added in 2007, and our dependency on net/avahi-app has always existed (since area51 r3659).

This could very well be an argument in favor of removing the MDNSRESPONDER option altogether (it's not clear to me how it was ever used even though miwi added it as a missing dependency in area51 r3671).

Interesting. I'd be in favour of removing it given my work in D1021.

alonso edited edge metadata.

I've updated the patch. I was using capitalized constants because that's how they're listed in http://www.cmake.org/Wiki/CMake:VariablesListsStrings and thought bumping PORTREVISION was ok as previous builds might have an untracked runtime dependency on Avahi.

In D1031#4, @rakuco wrote:

Make sure the style of CMAKE_ARGS is consistent with the rest of the file (i.e. replace ON/OFF with On/Off).

Plus we tend to group all variables related to an option (so AVAHI_LIB_DEPENDS/AVAHI_CMAKE_* then the corresponding MDNSRESPONDER_* variables).

And don't bump PORTREVISION — there is no need for rebuilding the package.

Are you sure? Looking at kdelibs's dnssd/CMakeLists.txt, we were indeed never building the mDNSResponder backend at all, even with our MDNSRESPONDER option defaulting to on. Since we hard-depend on net/avahi-app, HAVE_AVAHI in CMakeLists.txt was always set and we were always building the Avahi code.

However, taking one step back this also means that we've never built the mDNSResponder backend at all, at least for a long time (this can be partially verified by looking at the beefy{1,2} logs for the port). The detection code in kdelibs was added in 2007, and our dependency on net/avahi-app has always existed (since area51 r3659).

This could very well be an argument in favor of removing the MDNSRESPONDER option altogether (it's not clear to me how it was ever used even though miwi added it as a missing dependency in area51 r3671).

Avahi is used by some other ports, but in 2007 there were less Avahi users and therefore less chance to have Avahi installed and silently be used by kdelibs, so back then it might have been in use by more people.

Note that removing MDNSRESPONSER wouldn't introduce a hard dependency on AVAHI, as kdelibs provides a dummy backend if no ZEROCONF backend is found.

Avahi is used by some other ports, but in 2007 there were less Avahi users and therefore less chance to have Avahi installed and silently be used by kdelibs, so back then it might have been in use by more people.

Not really, unless I'm missing something obvious: since in addition to the dependency on net/avahi-libdns via the "AVAHI" option we've always depend on net/avahi-app, which contains the header that is used to detect Avahi's presence by kdelibs.

Note that removing MDNSRESPONSER wouldn't introduce a hard dependency on AVAHI, as kdelibs provides a dummy backend if no ZEROCONF backend is found.

The dummy backend is only built if neither mDNSResponder nor Avahi are found, but since we always depend on the port that provides the header used to check if Avahi is present or not, we'd still have a hard dependency on Avahi. This would only change if the dependency on net/avahi-app became optional.

In D1031#9, @rakuco wrote:

Avahi is used by some other ports, but in 2007 there were less Avahi users and therefore less chance to have Avahi installed and silently be used by kdelibs, so back then it might have been in use by more people.

Not really, unless I'm missing something obvious: since in addition to the dependency on net/avahi-libdns via the "AVAHI" option we've always depend on net/avahi-app, which contains the header that is used to detect Avahi's presence by kdelibs.

Note that removing MDNSRESPONSER wouldn't introduce a hard dependency on AVAHI, as kdelibs provides a dummy backend if no ZEROCONF backend is found.

The dummy backend is only built if neither mDNSResponder nor Avahi are found, but since we always depend on the port that provides the header used to check if Avahi is present or not, we'd still have a hard dependency on Avahi. This would only change if the dependency on net/avahi-app became optional.

I go for simplicity: lets leave hard dependency on avahi-app and remove ZEROCONF/AVAHI/MDNSRESPONDER options.

In D1031#10, @makc wrote:
In D1031#9, @rakuco wrote:

Avahi is used by some other ports, but in 2007 there were less Avahi users and therefore less chance to have Avahi installed and silently be used by kdelibs, so back then it might have been in use by more people.

Not really, unless I'm missing something obvious: since in addition to the dependency on net/avahi-libdns via the "AVAHI" option we've always depend on net/avahi-app, which contains the header that is used to detect Avahi's presence by kdelibs.

Note that removing MDNSRESPONSER wouldn't introduce a hard dependency on AVAHI, as kdelibs provides a dummy backend if no ZEROCONF backend is found.

The dummy backend is only built if neither mDNSResponder nor Avahi are found, but since we always depend on the port that provides the header used to check if Avahi is present or not, we'd still have a hard dependency on Avahi. This would only change if the dependency on net/avahi-app became optional.

I go for simplicity: lets leave hard dependency on avahi-app and remove ZEROCONF/AVAHI/MDNSRESPONDER options.

Patch updated.

Now it makes sense to bump PORTREVISION ;-) Since this version of the patch removes dependencies from the port, you need to bump PORTREVISION.

In D1031#13, @rakuco wrote:

Now it makes sense to bump PORTREVISION ;-) Since this version of the patch removes dependencies from the port, you need to bump PORTREVISION.

I see. Updated again.

rakuco edited edge metadata.

Looks good, thanks. Please make sure you are as verbose as possible in your commit message, explaining how we came to the conclusion that it made sense to drop these options altogether and Rui's plans in D1021.

This revision is now accepted and ready to land.Nov 1 2014, 9:33 PM

Commited to ports in revision 372093. We might want to prever Avahi over mDNSResponder in cups too which I'm proposing D1084.