Re: squid3 future directory structure

> On Thu, 2008-02-14 at 11:45 +1300, Amos Jeffries wrote:
>> > http://wiki.squid-cache.org/Features/SourceLayout
>
>> Added ICMP to your list of components. It's a clear-cut one now.
>
> Thank you. Can you lead this activity? We need somebody who will drive
> the discussion and oversee actual changes...
>
>> 1) Should we use squid/src/squid/ root for most sources to include
>> header
>> files as <squid/group/file.h>? This may be required for installed
>> headers
>> and 3rd party code using those headers.
>>
>> I'm undecided on this one. Lack of info to base the decision on. It will
>> really depend on the descision of whether or not to publish the headers
>> for external use.
>> I am inclined towards the publishing, but not towards the
>> squid/src/squid
>> hack we need to do.
>
> Yeah. I posted a separate message on eCAP that has an alternative to
> exposing Squid headers and libraries. Perhaps that would work better.
>
>> 2) Where to put OS-compatabilities wrappers that are currently located
>> in
>> squid/lib and squid/include?
>>
>> I like them where they are. It's the extras that have been added there
>> (guilty!) and the mixed styles of compatibility coding that are
>> confusing
>> things.
>
> I do not like the generic says-nothing names "lib" and "include". I also
> do not like that the two directories pollute the top-level directory.
> Can we, perhaps, agree on something like
>
> squid/compat/include
> squid/compat/lib
>

I'd agree with that.

>> I'm sorry Duane, but the use you seem to like of adding "Squid_" brings
>> to
>> mind more of 'completely re-written for squid, with different behaviour
>> or
>> usage' function.
>
> The problem with "xFoo" is that other libraries we link with might have
> their own "xFoo".
>
> A C++ solution for this is namespaces, I guess, but it would require
> more work to implement that approach in a clean way.
>
>> 3) Where to put 3rd party libraries that are currently located in
>> squid/lib and squid/include?
>>
>> ./src/dependancies/ ??
>> ./dependancies/ ??
>>
>> Definately split from the compat files though.
>
> How about
>
> squid/import/
>
> It is more specific, shorter, and easier to spell :-).

Yes, that works.

>
>> 6) Should directory names use just_small, CamelCase, or CAPS letters?
>>
>> I Think CamelCase like we do for files and classes, with acroynms being
>> upper case is working. When we can make the converted and re-used legacy
>> files from lower-only to CamelCase it will sit better than now.
>
> Any chance to convince you and others that HTTPReply is not as readable
> as HttpReply?

Some, but not a lot :-)
I'm constantly encountering syntax and typo errors because HTTP is not
always spelt upper-case in class names.

>
> If we start using namespaces for protocols, then this becomes a
> non-issue because HTTP::Reply reads just fine. Perhaps this should be a
> separate question. Should we start using namespaces for protocols and
> other important groups? I think we should.

Yes on both counts. its a big change, but big changes and goals are what
we are about these days. Working up to it slowly would be fine, with a
better definition of where and what before any code goes in, but I think
it should be one of the end-goals.

>
>> That said, this may impact the /usr/local/include descision. I think
>> there
>> is some tradition of lower-case with underscores on most OS.
>
> I am not sure that tradition applies to C++ stuff or "modern" code in
> general.

Meybe yes, meybe no. I haven't seen enough C++ code in /usr/* to judge it
properly by.

Amos
Received on Thu Feb 14 2008 - 16:24:23 MST