> Hello, > > I have created the following wiki page to see if we can agree on how > to define future subdirectories and what to move there. This can be a > Squid 3.2 feature, I think. > > http://wiki.squid-cache.org/Features/SourceLayout > > Amos, do you want to lead this activity? I have already covered about 75 > files out of 284 in src/ (not counting the differences in extensions) to > bootstrap the process? > > Thank you, > > Alex. >
Added ICMP to your list of components. It's a clear-cut one now. As to your questions. I think: 1) Should we use squid/src/squid/ root for most sources to include header files as <squid/group/file.h>? This may be required for installed headers and 3rd party code using those headers. I'm undecided on this one. Lack of info to base the decision on. It will really depend on the descision of whether or not to publish the headers for external use. I am inclined towards the publishing, but not towards the squid/src/squid hack we need to do. 2) Where to put OS-compatabilities wrappers that are currently located in squid/lib and squid/include? I like them where they are. It's the extras that have been added there (guilty!) and the mixed styles of compatibility coding that are confusing things. The schema I have been working to for these is that if a system library function has been replaced or added for compat. It has a name starting with 'x' (extended!) for use in the general squid code and a header file that has: #if its-not-needed #define xFoo Foo #else // its needed! void xFoo(...); #endif That makes for slightly smaller code and clearly just an alternate version of the library call. Developers can use the xFoo knowing it has the same behaviour and pre/post-conditions as can be found anywhere online. BUT, an implementation that works better in squid. I'm sorry Duane, but the use you seem to like of adding "Squid_" brings to mind more of 'completely re-written for squid, with different behaviour or usage' function. 3) Where to put 3rd party libraries that are currently located in squid/lib and squid/include? ./src/dependancies/ ?? ./dependancies/ ?? Definately split from the compat files though. 4) Can we remove Foo prefix from FOO/FooSomething.h file names? The prefix carries no additional information and is probably not required for modern compilers, especially in C++ world. I'd prefer the filenames matching the (single!) class defined inside. Standard C++ practice for some. That means some need a Foo/FooX others just Foo/XYZ. 5) Should client- and server- side files be separated? I think so. The combination is whats most confusing to me in squid at present. Identifying what file changes impact what side of the transaction. 6) Should directory names use just_small, CamelCase, or CAPS letters? I Think CamelCase like we do for files and classes, with acroynms being upper case is working. When we can make the converted and re-used legacy files from lower-only to CamelCase it will sit better than now. That said, this may impact the /usr/local/include descision. I think there is some tradition of lower-case with underscores on most OS. Amos