On Sat, 2008-04-26 at 00:33 +1200, Amos Jeffries wrote: > So why not put that in compat/? > Well, I'm imagining the compat/ parent directory itself having stuff > like the MD5.h specific small-scale compat which components might need > to share, but not the whole of squid. The semi-critical bits as I think > of them. > compat/includes and compat/lib you mentioned in your plans as being > propose for autoconf to perform complete squid-wide replacement of > missing header files or functions. > I thought of bits as the equivalent for manual developer use instead of > cluttering those up again.
The critical versus semi-critical (or manual versus automated?) distinction between what should go into compat/ and what should go into compat/bits is still not clear to me, but I will try to figure it out as we add stuff. If you are confident we need this, let's not waste time on this discussion. Just correct me if I start putting stuff in the wrong directory. With bzr, it should not be difficult to move it. > > What will happen is that you will have to place two-line wrappers in > > compat/ so that the rest of the code can get access to some of the stuff > > in compat/bits/. That's not a big deal. > > May not be a big deal but I don't understand you. > Please explain by what you mean by having to us two-line wrappers. And > what form they would need to take (#if ... #endif ?? or makefile: if ... > fi ??). I was talking about include files. See /usr/include/c ++/*/map, /usr/include/c++/*/string and other GCC STL files for examples of such wrappers. Those STL header wrappers have some logic/need in them; hopefully ours will too. Thank you, Alex.
