Re: squid3 future directory structure

[Robert Collins]

On Tue, 2008-02-26 at 20:37 -0700, Alex Rousskov wrote:
> On Wed, 2008-02-27 at 11:33 +1100, Robert Collins wrote:
> > On Tue, 2008-02-26 at 16:50 -0700, Alex Rousskov wrote:
> > > 
> > > That #include line would be illegal in cleaned up sources, of course.
> > > You are supposed to say "include1/Foo.h" or equivalent. That's why
> > > duplicating group in file names may become unnecessary:
> > > Group/GroupFoo.h
> > > becomes Group/Foo.h
> > 
> > I think for graceful failures its better to eliminate failure modes we
> > can predict when it is cheap to do so.
> > 
> > Using consistently lowercase file names on disk will do that.
> 
> So you would recommend something like 
> 
>   http/request_method.cc
> and
>   acl/request_header_strategy.h
> 
> right?

yes.

-Rob
-- 
GPG key available at: .


signature.asc
Description: This is a digitally signed message part

Re: squid3 future directory structure

[Kinkie]

On Wed, Feb 27, 2008 at 4:37 AM, Alex Rousskov
<[EMAIL PROTECTED]> wrote:
> On Wed, 2008-02-27 at 11:33 +1100, Robert Collins wrote:
>  So you would recommend something like
>
> http/request_method.cc
>  and
> acl/request_header_strategy.h

I prefer not to use camelcase when it comes to filenames, so count my
vote for this proposal.

-- 
/kinkie

Re: squid3 future directory structure

[Alex Rousskov]

On Wed, 2008-02-27 at 11:33 +1100, Robert Collins wrote:
> On Tue, 2008-02-26 at 16:50 -0700, Alex Rousskov wrote:
> > 
> > That #include line would be illegal in cleaned up sources, of course.
> > You are supposed to say "include1/Foo.h" or equivalent. That's why
> > duplicating group in file names may become unnecessary:
> > Group/GroupFoo.h
> > becomes Group/Foo.h
> 
> I think for graceful failures its better to eliminate failure modes we
> can predict when it is cheap to do so.
> 
> Using consistently lowercase file names on disk will do that.

So you would recommend something like 

http/request_method.cc
and
acl/request_header_strategy.h

right?

Thank you,

Alex.

Re: squid3 future directory structure

[Robert Collins]

On Tue, 2008-02-26 at 16:50 -0700, Alex Rousskov wrote:
> 
> That #include line would be illegal in cleaned up sources, of course.
> You are supposed to say "include1/Foo.h" or equivalent. That's why
> duplicating group in file names may become unnecessary:
> Group/GroupFoo.h
> becomes Group/Foo.h

I think for graceful failures its better to eliminate failure modes we
can predict when it is cheap to do so.

Using consistently lowercase file names on disk will do that.

-Rob

-- 
GPG key available at: .
> 


signature.asc
Description: This is a digitally signed message part

Re: squid3 future directory structure

[Alex Rousskov]

On Wed, 2008-02-27 at 07:59 +1100, Robert Collins wrote:
> On Fri, 2008-02-22 at 20:11 +0100, Guido Serassio wrote:
> > Hi Alex,
> > 
> > At 19:29 22/02/2008, Alex Rousskov wrote:
> > >On Fri, 2008-02-22 at 19:23 +0100, Guido Serassio wrote:
> > >
> > > > Changing the case of files/dir will not be a problem if we will avoid
> > > > upper/lower case collisions.
> > >
> > >This only applies to files in the same directory, right?
> > 
> > Sure.
> > 
> > >  AFAICT,
> > >filenames from different directories may still collide and even have
> > >identical case.
> > 
> > Yes, absolutely no problems here.
> 
> Actually there is a problem.
> 
> touch include1/Foo.h
> touch include2/foo.h
> 
> g++ -I include1 -I include2 foo.cc
> 
> foo.cc:
> #include "foo.h"

That #include line would be illegal in cleaned up sources, of course.
You are supposed to say "include1/Foo.h" or equivalent. That's why
duplicating group in file names may become unnecessary: Group/GroupFoo.h
becomes Group/Foo.h

Alex.

Re: squid3 future directory structure

[Robert Collins]

On Fri, 2008-02-22 at 20:11 +0100, Guido Serassio wrote:
> Hi Alex,
> 
> At 19:29 22/02/2008, Alex Rousskov wrote:
> >On Fri, 2008-02-22 at 19:23 +0100, Guido Serassio wrote:
> >
> > > Changing the case of files/dir will not be a problem if we will avoid
> > > upper/lower case collisions.
> >
> >This only applies to files in the same directory, right?
> 
> Sure.
> 
> >  AFAICT,
> >filenames from different directories may still collide and even have
> >identical case.
> 
> Yes, absolutely no problems here.

Actually there is a problem.

touch include1/Foo.h
touch include2/foo.h

g++ -I include1 -I include2 foo.cc

foo.cc:
#include "foo.h"
...

*boom*

-Rob

-- 
GPG key available at: .
> 


signature.asc
Description: This is a digitally signed message part

Re: squid3 future directory structure

[Alex Rousskov]

On Sat, 2008-02-23 at 14:47 +0100, Henrik Nordström wrote:
> fre 2008-02-22 klockan 11:29 -0700 skrev Alex Rousskov:
> > On Fri, 2008-02-22 at 19:23 +0100, Guido Serassio wrote:
> > 
> > > Changing the case of files/dir will not be a problem if we will avoid 
> > > upper/lower case collisions.
> > 
> > This only applies to files in the same directory, right? AFAICT,
> > filenames from different directories may still collide and even have
> > identical case.
> 
> Bad idea even then. The files is easily confused by humans. If someone
> says file.cc in a dicsussion do he mean src/File.cc or lib/File.cc?

> And a really really bad idea for include files unless in a specific
> include subdir (#include "subdir/file.h"). For example case-insensitive
> filesystems will fail if both include/ and src/ has a .h file of the
> same name differing only in case.
> 
> Also not sure what happens if we (or libtool) build a common lib archive
> of objects with the same name from differnt directories, but I think
> that will fail as well.

The only real problem that bothers me personally is that __FILE__ does
not include the directory name and, hence, is less useful in assert
statements and such.

Humans can use module/Foo almost as well as current MODULEFoo and
libraries appear to work fine in my experience. Include statements must
use module/ directory, of course.

Cheers,

Alex.

Re: squid3 future directory structure

[Henrik Nordström]

fre 2008-02-22 klockan 11:29 -0700 skrev Alex Rousskov:
> On Fri, 2008-02-22 at 19:23 +0100, Guido Serassio wrote:
> 
> > Changing the case of files/dir will not be a problem if we will avoid 
> > upper/lower case collisions.
> 
> This only applies to files in the same directory, right? AFAICT,
> filenames from different directories may still collide and even have
> identical case.

Bad idea even then. The files is easily confused by humans. If someone
says file.cc in a dicsussion do he mean src/File.cc or lib/File.cc?

And a really really bad idea for include files unless in a specific
include subdir (#include "subdir/file.h"). For example case-insensitive
filesystems will fail if both include/ and src/ has a .h file of the
same name differing only in case.

Also not sure what happens if we (or libtool) build a common lib archive
of objects with the same name from differnt directories, but I think
that will fail as well.

Regards
Henrik


signature.asc
Description: Detta är en digitalt signerad	meddelandedel

Re: squid3 future directory structure

[Guido Serassio]

Hi Alex,

At 19:29 22/02/2008, Alex Rousskov wrote:

On Fri, 2008-02-22 at 19:23 +0100, Guido Serassio wrote:

> Changing the case of files/dir will not be a problem if we will avoid
> upper/lower case collisions.

This only applies to files in the same directory, right?


Sure.


 AFAICT,
filenames from different directories may still collide and even have
identical case.


Yes, absolutely no problems here.

Regards

Guido



-

Guido Serassio
Acme Consulting S.r.l. - Microsoft Certified Partner
Via Lucia Savarino, 1   10098 - Rivoli (TO) - ITALY
Tel. : +39.011.9530135  Fax. : +39.011.9781115
Email: [EMAIL PROTECTED]
WWW: http://www.acmeconsulting.it/

Re: squid3 future directory structure

[Alex Rousskov]

On Fri, 2008-02-22 at 19:23 +0100, Guido Serassio wrote:

> Changing the case of files/dir will not be a problem if we will avoid 
> upper/lower case collisions.

This only applies to files in the same directory, right? AFAICT,
filenames from different directories may still collide and even have
identical case.

Thanks,

Alex.

Re: squid3 future directory structure

[Guido Serassio]

Hi Alex,

At 00:25 20/02/2008, Alex Rousskov wrote:

>
> We had many problems on Windows in the past during the C++ refactoring.

Do you still have those problems (we do use many capitalization styles
right now)? Or is mixed case only a problem when we rename/move things
and then there is no problem once things settle down? If it is the
latter, then polishing capitalization (e.g., converting all dirs to
lower_case) would create problems for you again!


The problem was generated from file names different only in the case, 
like file.cc and File.cc: for the Windows file system they are the 
same file, but not for Linux/Unix.


Currently there are no special problems, the only annoying thing is 
that sometime CVS doesn't like the case of a file, but deleting it 
and running CVS again fixes the problem


Changing the case of files/dir will not be a problem if we will avoid 
upper/lower case collisions.


Regards

Guido



-

Guido Serassio
Acme Consulting S.r.l. - Microsoft Certified Partner
Via Lucia Savarino, 1   10098 - Rivoli (TO) - ITALY
Tel. : +39.011.9530135  Fax. : +39.011.9781115
Email: [EMAIL PROTECTED]
WWW: http://www.acmeconsulting.it/

Re: squid3 future directory structure

[Alex Rousskov]

On Tue, 2008-02-19 at 22:48 +0100, Guido Serassio wrote:
> At 04:56 15/02/2008, Robert Collins wrote:
> > >
> > > Some, but not a lot :-)
> > > I'm constantly encountering syntax and typo errors because HTTP is not
> > > always spelt upper-case in class names.
> >
> >I'd prefer lowercase always for directories.
> >
> >filenames and CaSe are always headaches on windows :)
> 
> +1
> 
> We had many problems on Windows in the past during the C++ refactoring.

Do you still have those problems (we do use many capitalization styles
right now)? Or is mixed case only a problem when we rename/move things
and then there is no problem once things settle down? If it is the
latter, then polishing capitalization (e.g., converting all dirs to
lower_case) would create problems for you again!

Thank you,

Alex.

Re: squid3 future directory structure

[Guido Serassio]

Hi,

At 04:56 15/02/2008, Robert Collins wrote:

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

I'd prefer lowercase always for directories.

filenames and CaSe are always headaches on windows :)


+1

We had many problems on Windows in the past during the C++ refactoring.

Regards

Guido



-

Guido Serassio
Acme Consulting S.r.l. - Microsoft Certified Partner
Via Lucia Savarino, 1   10098 - Rivoli (TO) - ITALY
Tel. : +39.011.9530135  Fax. : +39.011.9781115
Email: [EMAIL PROTECTED]
WWW: http://www.acmeconsulting.it/

Re: squid3 future directory structure

[Robert Collins]

On Fri, 2008-02-15 at 12:24 +1300, Amos Jeffries wrote:
> 
> >> 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.

I'd prefer lowercase always for directories.

filenames and CaSe are always headaches on windows :)

-Rob
-- 
GPG key available at: .
> 


signature.asc
Description: This is a digitally signed message part

Re: squid3 future directory structure

[Amos Jeffries]

> 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 ? 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

Re: squid3 future directory structure

[Alex Rousskov]

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 ? 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'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 :-).

> 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?

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.

> 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.

Thank you,

Alex.

Re: squid3 future directory structure

[Amos Jeffries]

>
> On Thu, 2008-02-14 at 11:45 +1300, Amos Jeffries wrote:
>> I'd prefer the filenames matching the (single!) class defined inside.
>> Standard C++ practice for some.
>
> Sure.
>
>> That means some need a Foo/FooX others just Foo/XYZ.
>
> But we can use namespaces and rename classes as needed to avoid long
> class names in a local context.

Those would be the few that need Foo/XYZ files to match their short names
then.

Amos

Re: squid3 future directory structure

[Alex Rousskov]

On Thu, 2008-02-14 at 11:45 +1300, Amos Jeffries wrote:
> I'd prefer the filenames matching the (single!) class defined inside.
> Standard C++ practice for some. 

Sure.

> That means some need a Foo/FooX others just Foo/XYZ.

But we can use namespaces and rename classes as needed to avoid long
class names in a local context.

Thanks,

Alex.

Re: squid3 future directory structure

[Amos Jeffries]

> Hello,
>
> I have created the following wiki page to see if we can agree on how
> to define future subdirectories and what to move there. This can be a
> Squid 3.2 feature, I think.
>
>   http://wiki.squid-cache.org/Features/SourceLayout
>
> Amos, do you want to lead this activity? I have already covered about 75
> files out of 284 in src/ (not counting the differences in extensions) to
> bootstrap the process?
>
> Thank you,
>
> Alex.
>

Added ICMP to your list of components. It's a clear-cut one now.

As to your questions. I think:

1) Should we use squid/src/squid/ root for most sources to include header
files as ? 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.


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.

The schema I have been working to for these is that if a system library
function has been replaced or added for compat. It has a name starting
with 'x' (extended!) for use in the general squid code and a header file
that has:

#if its-not-needed
#define xFoo   Foo
#else // its needed!
void xFoo(...);
#endif

That makes for slightly smaller code and clearly just an alternate version
of the library call. Developers can use the xFoo knowing it has the same
behaviour and pre/post-conditions as can be found anywhere online. BUT, an
implementation that works better in squid.

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.


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.


4) Can we remove Foo prefix from FOO/FooSomething.h file names? The prefix
carries no additional information and is probably not required for modern
compilers, especially in C++ world.

I'd prefer the filenames matching the (single!) class defined inside.
Standard C++ practice for some. That means some need a Foo/FooX others
just Foo/XYZ.


5) Should client- and server- side files be separated?

I think so. The combination is whats most confusing to me in squid at
present. Identifying what file changes impact what side of the
transaction.


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.

That said, this may impact the /usr/local/include descision. I think there
is some tradition of lower-case with underscores on most OS.



Amos

Re: squid3 future directory structure

[Alex Rousskov]

Hello,

I have created the following wiki page to see if we can agree on how
to define future subdirectories and what to move there. This can be a
Squid 3.2 feature, I think.

  http://wiki.squid-cache.org/Features/SourceLayout

Amos, do you want to lead this activity? I have already covered about 75
files out of 284 in src/ (not counting the differences in extensions) to
bootstrap the process?

Thank you,

Alex.

Re: squid3 future directory structure

[Alex Rousskov]

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  as opposed to
> >  or, horror, ?
> > 
> > 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  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  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 
and an application that says 
#include  
because the two may mean a different config.h (I have seen that happen).

Having a  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,

Alex.

Re: squid3 future directory structure

[Amos Jeffries]

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//*

/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  as opposed to
 or, horror, ?

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  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  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.