|
Boost : |
From: Nikita Kniazev (nok.raven_at_[hidden])
Date: 2021-08-27 02:33:15
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk