[squid-dev] [RFC] The situation with helpers/

Amos Jeffries squid3 at treenet.co.nz
Tue Jan 5 03:58:51 UTC 2016


The SBuf and CharacterSet patch auditing has brought up the questions of
why helpers/ is separate from src/, built first, what cross-dependency
there can be, and even why we are bundling C++ helpers to begin with.

So lets clarify it formally once and for all.

Q1: why is helpers/ built before src/ ?

* originally most of the helpers were actually C helpers, not C++. We
had significant build errors some obvious some subtle related to
compiler include paths pulling in src/ C++ content and dependencies.

* building first enforces that src/ obects do not exist in the build
directory on clean builds, so cannot be depended on by mistake.

TODAY:
 a) that C vs C++ distinction non longer exists. If the dependencies are
re-introduced they will be simply an annoyance with extra LDADD lists to
be maintained and increased helper binary sizes. Not a build or run-time
error.

 b) several of the helpers are actually very tightly integrated and even
built within src/ (pinger, diskd, ssl_crtd etc).


Which brings us to ..

Q2: why is helpers/ separate from src/ ?
  should we shuffle them back to src/*/helpers/ directories on a
per-component basis ?

* the current configure.ac logic would as easily work for scanning
src/*/helpers/X as for helpers/*/X

* the move would simplify the bundle size by a few Makefiles.

* the move would simplify the use of our fancy custom logic designs in
helpers.

* it does somewhat hinder anyone wanting to manually build a single
helper. Though I have not heard of anyone doing so in many years.

* it does mean we should probably discard the goal of having the helpers
be demo code examples for people to base their custom helpers on.



Amos



More information about the squid-dev mailing list