Re: squid3 future directory structure
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 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
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.
