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.
HTH,
Alex.
