On 9/20/22 02:34, Francesco Chemolli wrote:
I agree that modules that can always be built, should be. Such modules
should have no guarding #ifdefs. I think this is the set of modules
that
your proposal is targeting, but please correct me if I am wrong. FWIW,
this design stems from an even more general/fundamental rule of thumb:
Do not add unnecessary #ifdefs.
I agree. We could also work on better isolation, by restricting
#ifdef-guarded areas
to specific delegate classes, and then using c++ features (e.g. if
constexpr, eventually) to
disable the callsites.
Yes, of course, but I would start with modules/features that require no
significant refactoring. I am not sure what the best candidates are, but
I would evaluate ident, cache digests, htcp, and wccp first (these are
from your own list of candidates).
For example, a feature like unlinkd (also on your list) would require
adding a default-disabled configuration option (unlinkd_enable, similar
to pinger_enable) or introducing support for a special program location
spelling like "none". Adding either would break existing configurations
that willingly run unlinkd. There are probably a few features/modules
that do _not_ require such disruptive configuration changes. I would
start with those.
However, there is a precondition: Any always-built optional feature
with
a potentially significant performance impact or a controversial side
effect should be disabled by default (via squid.conf). Satisfying this
precondition will require code changes.
Yes, I agree.
Glad we are on the same page!
I recommend giving Amos more time to leave feedback before spending time
on code changes, but if we are all in agreement, then I am looking
forward to PRs reducing the number of unnecessary #ifdefs. To minimize
overheads, please use one PR per module/feature and avoid opening
multiple concurrent PRs (at least until it is clear that we are on the
same page regarding the overall approach to the corresponding code
modifications).
Thank you,
Alex.
_______________________________________________
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev
