What do you suggest as a solution? I agree that autodetection with no way to override it is bad. (In my not yet finished CMake guidelines, I advocate for only using autodetection to determine the default for the configuration option, while still allowing the user to override it.) But how does this translate to something actionable? How would you have written the Nowide build/Jamfile?
Sigh, if I had a good solution I would have presented it. An easiest and no-brainer way to tackle this is to have a per-library variable `is-boost-<library>-required/optional` on which library would have to omit checks (do not import Boost.Config, and do not pass checks that return `<build>no` to project/library requirements): ``` if is-boost-<library>-optional { import ../../config/checks/config : requires ; $(do-not-build-if) = [ requires ... ] ; } lib boost_<library> : ... : $(do-not-build-if) ; ``` However, in my opinion, a library must never add `<build>no` to its requirements by itself. Something external should decide if the build/checks failure is fatal or not: ``` rule can-be-built ( ... ) { import ../../config/checks/config : requires ; return [ requires ... ] ; } boost-install boost_<library> : @can-be-built ; ``` It would be perfect if the library could provide a meaningful explanation why it could not be built/describe not satisfied requirements, but that obviously requires a way more sophisticated system.
This is not a Mailman problem, this is a problem with how you are replying or your mail client setup. Other users with gmail seem to not have reply problems so I suspect it is not a gmail specific issue. A quick look reveals that at least one concern is that your headers lack the "in reply to".
I am subscribed to the daily digest, I cannot reply to a message because I do not receive emails even if someone replied to my message or posted something to a thread I interested to be updated more frequently.
As a side-note: there are non-trivial issues with upgrading to mailman v3; however, hopefully we will be able to upgrade things in the not-to-far-off future.
Thanks for working on that.