[squid-dev] Proposal: switch to always-build for some currently optional features

[Alex Rousskov]

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.