Re: squid3 future directory structure

Alex Rousskov wrote:
> On Tue, 2008-02-12 at 11:19 +1300, Amos Jeffries wrote:
>>> 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" :-).
>> My reading of the AC_REPLACE_FUNCS(...) is that it when it detects a
>> portability issue it adds include/missing-function.h and
>> lib/missing-function.c to the build list.
>> We are using that for several library functions.
>
> Does AC_CONFIG_LIBOBJ_DIR control the name of the "lib/" directory?
>
> Macro: AC_CONFIG_LIBOBJ_DIR (DIRECTORY)
> Specify that `AC_LIBOBJ' replacement files are to be found in
> DIRECTORY, a name relative to the top level of the source tree.
> The replacement directory defaults to `.', the top level
> directory, and the most typical value is `lib', corresponding to
> `AC_CONFIG_LIBOBJ_DIR([lib])'.
>
> `configure' might need to know the replacement directory for the
> following reasons: (i) some checks use the replacement files, (ii)
> some macros bypass broken system headers by installing links to the
> replacement headers (iii) when used in conjunction with Automake,
> within each makefile, DIRECTORY is used as a relative path from
> `$(top_srcdir)' to each object named in `LIBOBJS' and `LTLIBOBJS',
> etc.
>
>>>> ?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".
>> I'm not disagreeing on lib/name/. Just splitting the so its kept seperate
>> from the raw portability files.
>
> Right. FWIW, the dir/many-files-here* plus dir/many-subdirs-here/*
> combination always looks messy and awkward to search/navigate to me. I
> would prefer just dir/many-subdirs-here/* but it is not a big deal.
>
>>>> /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/common ?? (I think you were against a /src/core earlier)
>
> "Common" is good enough to me as it reflects the purpose fairly well.
> "Core" would be wrong because this directory is for little things used
> throughout the project rather than some kind of a monolithic kernel
> holding everything together.
>
> BTW, we should not name that subdir "core" regardless of its purpose --
> I have tried that in another project and got bitten by systems/programs
> that treat that name specially :-).
>
>
> Another big related question is the header path problem: Do we want to
> have something like squid/src/squid/module/*, which allows you to refer
> to Squid include files as <squid/module/something.h> as opposed to
> <module/something.h> or, horror, <something.h>?
>
> AFAIK, this arrangement is necessary if you:
>
> 1) want to install some of the header files from subdirs (e.g., for
> folks who build 3rd party eCAP modules);
>
> 2) do not want to pollute global header namespace with likely-to-clash
> file names like Log.h or select.h; and
>
> 3) do not want to keep all header files separately from .cc files, using
> the squid/include/module/something.h template (which I find much uglier
> and more awkward to use than squid/src/squid/module/ where related .h
> and .cc files are kept in one module/ directory).
>
> There may be better solutions to the header path problem, but I do not
> know them.

I'm more in favour of <module/something.h> when compiling a bundle of
source. As you say, keeping the .h and .cc together.

I may have barked up the wrong tree and down again. But didn't you have
a plan earlier to migrate some headers into /usr/include/squid/*?
The desired <squid/module/something.h> would be the resulting
side-effect of that for _external_ applications or modules.

Amos

-- 
Please use Squid 2.6STABLE17+ or 3.0STABLE1+
There are serious security advisories out on all earlier releases.