Re: squid3 future directory structure

2008-02-28 Thread 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: http://www.robertcollins.net/keys.txt.


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


Re: squid3 future directory structure

2008-02-27 Thread 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

2008-02-26 Thread 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: http://www.robertcollins.net/keys.txt.
 


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


Re: squid3 future directory structure

2008-02-26 Thread 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

2008-02-26 Thread 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

2008-02-25 Thread 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

2008-02-23 Thread 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

2008-02-22 Thread 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

2008-02-22 Thread 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

2008-02-22 Thread 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

2008-02-19 Thread 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

2008-02-19 Thread 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

2008-02-14 Thread 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 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'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

2008-02-14 Thread 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 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




Re: squid3 future directory structure

2008-02-14 Thread 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: http://www.robertcollins.net/keys.txt.
 


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


Re: squid3 future directory structure

2008-02-13 Thread 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

2008-02-13 Thread 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

2008-02-13 Thread 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 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.


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

2008-02-13 Thread 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

2008-02-12 Thread 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/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.


Re: squid3 future directory structure

2008-02-12 Thread 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 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,

Alex.




squid3 future directory structure

2008-02-11 Thread Alex Rousskov
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.