[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