On Tue, 2008-02-12 at 23:42 +1300, Amos Jeffries wrote:
> Alex Rousskov wrote:> 
> > 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.

Yes, I think the headers should be installed
in /usr/local/include/squid/module/*.h or equivalent, but to do that you
need to organize sources as squid/src/squid/module/ OR separate headers
from .cc files (I tried to outline why squid/src/squid/ is necessary
above). We both favor the former approach because it keeps .h and .cc
together. Again, there may be a better way to accomplish this, but I do
not know any.

Or did I misinterpret your concern?

Please note that since installed Squid headers are including other
installed Squid headers, both Squid headers and external applications
have to use the same path in #include statements. You should not have
installed headers that say 
        #include <common/config.h>
and an application that says 
        #include <squid/common/config.h> 
because the two may mean a different config.h (I have seen that happen).

Having a <squid/> prefix is a much safer/clean solution, IMO, but I am
worried others may not like the squid/src/squid arrangement. Hopefully
there is a better way of implementing this.

Thank you,


Reply via email to