-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
adds option ENABLE_AVAHI #97
Conversation
@guruofquality Is there a blocker for merging this change? |
I think its fine. I guess Im not sure of the different between ENABLE_AVAHI and automatically searching for package with AVAHI_FOUND. Is the idea to better support disabling use of avahi by silencing the warning printed when avahi is not found by passing |
A rule for good cmake options that gets handed around is: do exactly as selected with errors instead of fallbacks. I.e. I can update the PR to that scheme if you like? |
Yea I think your right. And I think the change as it is now makes sense to do. I also like the idea of AUTO/OFF/ON. I wonder if that plays badly with option() and how if() cmake treats variables as booleans. I feel like I rarely see this ON must succeed vs AUTO use if found. Like is there a convention here to follow? I feel like thats not the last time something like this will come up 😉 |
In my experience it works very well. E.g. (just to illustrate the form) set(ENABLE_AVAHI AUTO CACHE STRING "Enable Avahi support")
set_property(CACHE ENABLE_AVAHI PROPERTY STRINGS AUTO ON OFF)
if(ENABLE_AVAHI) # AUTO / ON
find_package(Avahi)
if(Avahi_FOUND)
message(STATUS "Avahi support will be compiled.")
ADD_DEFINITIONS(-DAVAHI)
elseif(ENABLE_AVAHI STREQUAL "AUTO")
message(STATUS "Avahi support not found, some features will be disabled.")
else()
message(FATAL_ERROR "Avahi support not found.")
endif()
else()
message(STATUS "Avahi support disabled.")
endif() |
I'd say in general having OTOH, I quite like the "build whatever I can get here now" option AUTO gives me. But I guess erroring with |
I see what you mean. Its not great for a package build or CI build to accidentally build features or not build features based on the development environment being different. My original intention at least was to have the build from source mode just "try its best" to enable features without specifying flags, if CI or build systems need more control, they will just have to code flags into the build scripts. So I think the AUTO scheme you mentioned is pretty good and has a decent balance of tradeoffs with the control when flags are specified. I'd say go ahead and take over the PR and add that AUTO scheme. 😁 Over-engineering a PR to disable avahi with a flag 😁 |
fb2acd8
to
4cd1d75
Compare
Done. I kept the original commit for reference so this should be Squash merged. This now also fixes inconsistent case in the cmake module, it honors the case as in Also I noticed that (the CI fails are just 404s downloading base files.) |
@grutz When you have time to test then let us know if this works for your case or is missing something. |
Looks great for my case! During build w/o AVAHI libs installed:
And on run:
|
You may need to reset and pull this branch (or clone again), the message should have been |
4cd1d75
to
e52b129
Compare
No description provided.