Looking at /usr/include on my Linux system, it seems that the vast majority of directory names are short acronyms. And yes, most have no meaning and are just used to disambiguate otherwise similar names (like prepending X or G before all your public function names).
Given that I don't find 1 compelling personally as I don't feel the need to change the world on this one :) Regarding 3, perhaps use ats as a directory name? Another question is how do we want to handle versions? Should we have: ats/ats-2.0.h ? gtk uses /usr/include/gtk-2.0 python in /usr/include/python2.5 gcc uses /usr/include/g++/4.1.2 Some folks also have a single .h which pulls in everything: /usr/local/include/gc.h pulls is just #include </usr/local/include/gc/gc.h> which pulls in everthing one needs from: /usr/local/include/gc/* I kind of like that. /usr/local/include/ats.h /usr/local/include/ats/ats.h /usr/local/include/ats/remap_api.h And for versions I would do: /usr/local/include/ats/2.0/ats.h where /usr/local/include/ats/ats.h would include the latest version and there might be multiple subdirectories if we have a compatibility layer at some point. john On 2/4/2010 3:16 PM, Bryan Call wrote: > Just to clarify my position: > > 1. ts is a crappy name for a directory, it has no meaning and it is like > naming a variable x or y. I believe that directories, files, variables, > functions, etc should have meaningful names. Most people use tab > complete or text complete by now or at least they should, so typing > shouldn't be an issue. > 2. "trafficserver" is already used for all other directory names > etc/trafficserver logs/trafficserver, etc.. We should have consistency > in the directory names. > 3. There is one other project that uses "ts" as a directory name. I am > not saying that there will be conflicts in the directory and file names, > but it would be damn confusing to have two projects dump their headers > in the same directory. > > Sorry if I didn't bring up these points earlier in the discussion... > > -Bryan > > On 02/04/2010 01:35 PM, Bryan Call wrote: >> There is already code that uses the ts directory for include files >> (simple google search, there might be others): >> >> http://isscvs.cern.ch/cgi-bin/viewcvs-all.cgi/TriDAS/trigger/ts/framework/src/common/CellOpInit.cc?revision=1.35&root=tridas&view=markup >> >> >> [x] ts_api.h >> [x] ${prefix}/trafficserver >> >> -Bryan >> >> On 02/03/2010 08:08 PM, Leif Hedstrom wrote: >>> So, I think the discussions have had enough time, the consensus is >>> definitely that we should clean up what we got. As such, we will move >>> both include files to be in the same directory in SVN, we will rename >>> RemapAPI.h to remap_api.h, and we will install the two header files >>> in a well defined include directory. Two things to vote on remains >>> (please cast votes within 72 hours): >>> >>> >>> InkApi.h rename: >>> ------------------------ >>> [ ] api.h >>> [ ] ts_api.h >>> [ ] sdkapi.h >>> >>> >>> Include directory name >>> --------------------------------- >>> >>> [ ] ${prefix}/ts >>> [ ] ${prefix}/trafficserver >>> >>> >>> >>> Include directives would hence look like the examples below >>> (depending on the outcome of the votes): >>> >>> #include <ts/remap_api.h> >>> #include <ts/api.h> -- or -- >>> #include <ts/ts_api.h> -- or -- >>> #include <ts/sdkapi.h> >>> >>> -- or -- >>> >>> #include <trafficserver/remap_api.h> >>> #include <trafficserver/api.h> -- or -- >>> #include <trafficserver/ts_api.h> -- or -- >>> #include <trafficserver/sdkapi.h> >>> >>> >>> Cheers! >>> >>> -- Leif >>> >> >> >
