On tor, 2007-10-11 at 20:17 -0600, Alex Rousskov wrote: > Hello, > > To support loadable modules, we may need to alter Squid sources layout > or installation procedure. This email discusses the problem and four > possible solutions. Please review and suggest the best path forward.
Possibly, but I prefer not supporting loadable modules except where there is very well defined boundaries. > While it is possible for a module to use headers and libraries from > Squid sources, doing so is a big and dangerous hack -- the sources are > not designed to be used externally and may be in an inconsistent state, > leading to unusable modules or, worse, subtle bugs. Very true. > AFAIK, the solution is for Squid to _install_ everything that a module > may needed. Since a module may manipulate many Squid objects, this > implies that Squid should install all header files (and possibly many > libraries). Currently, Squid does not install any headers. Only headers which have been cleaned up to a level of providing a stable interface should be exported for use by external modules. > The alternative is to install headers in /usr/local/squid/include/squid > directory (note squid at the end). Modules will include such headers as > "squid/foo.h", virtually eliminating the possibility of a conflict. We > use this approach with other projects, and it works well. Yes. > Unfortunately for Squid, its code would also have to refer to its > headers using the "squid/foo.h" pattern. That's fine. The headers that are candidates for this should be cleaned up to a level that they provide a stable interface, and moved to include/squid/ > As you know, current header > files are in in a "squid" directory. They are in "src". We could move > all files from "src" to "src/squid". We use that design in Factory > projects and it works well. However, CVS will lose all commit history if > we move the files! It's relatively easy to move files preserving history if that's important. But given my preference on what may be candidates for use by external modules I am not sure it matters much.. Regards Henrik
signature.asc
Description: This is a digitally signed message part
