On Tue, 2008-02-12 at 10:37 +1300, Amos Jeffries wrote:
> > When we get a better VCS, we should discuss moving include/ and lib/
> > stuff into src/ with the exception of 3rd party code. This would avoid
> > problems created by that artificial boundary.
>
> What I have been mulling over after seeing code heirarchy like this:
>
> /include + /lib == C library functions for portability (autotools
> requires these here).
In my experience, autotools do not require them to be there or those
requirements can be relaxed as needed. Our portability wrappers may
still use Squid-specific code so placing them outside of src/ is not a
good idea, IMO. There got to be a better reason to place something
outside of src/ than "autotools" :-).
> ?somewhere? == third party additions (currently /lib/<name>/*
/lib/name is not too bad. We can even do src/3rdparty/name or something
like that, but perhaps keeping that stuff outside of src/ is a good idea
even though it is also "source".
> /src/ == core code at lowest level
I would move it to src/base or src/backend or something like that. And
there should not be really many files there.
> /src/<module> == 'independant' module code. namely the files like existing
> ICAP, FS, Auth code. But making sure that all the other independant code
> gets its own sub-dirs too (thinking each server-side gateway, pinger,
> DNS?, ESI, Others?)
Yes, but "module" and "independent" should be treated loosely. For
example, logging may not be a "module" or "independent", but may need
its own directory. Same for memory management.
In short, when you have or want to have a bunch of Something*.{cc,h}
files, place them into src/Something/ directory.
Alex.
