class library header file naming and install conventions

["Jeff Hill" <johill@lanl.gov>]

All,

When designing a C++ class library whose name is pdq it seems that one might
implement one header file for every exported class, and follow some naming
rules. 

Here is a straw-man. Lots of other schemes are possible, and the only really
bad scheme is to follow no naming convention at all, I suppose.

o The C++ namespace is pdq (class lib names must be all lower case letters)
o The master header file's name is pdq.h
o Each exported class named Xxxx has a header file named pdq/Xxxx.h
o The master header file has '#include "pdq/Xxxx.h"' for each exported class
o The pdq.h is installed to $(EPICS_BASE)/include/pdq.h
o The pdq/Xxxx.h are installed to $(EPICS_BASE)/include/pdq/Xxxx.h
o The build system appears to implement this type of install now if, in the
build area, one has something like src/pdq/lib/pdq which contains the header
files (where they are installed from). Is that what we want? That (redundant
pdq in the path) could be initially somewhat confusing to the uninitiated,
and I don?t see any reason to place the header files in a subdirectory other
than to avoid changing the build system?
o The c/c++ files are named src/pdq/lib/Xxxx.cpp
o The documentation master goes in src/pdq/doc/pdq.html
o Maybe the class interface documentation goes in src/pdq/doc/pdq/Xxxx.html
(same concerns about redundant pdq in the path)

All comments appreciated. 

Thanks,

Jeff
______________________________________________________
Jeffrey O. Hill           Email        johill@lanl.gov
LANL MS H820              Voice        505 665 1831
Los Alamos NM 87545 USA   FAX          505 665 5107

Message content: TSPA

With sufficient thrust, pigs fly just fine. However, this is
not necessarily a good idea. It is hard to be sure where they
are going to land, and it could be dangerous sitting under them
as they fly overhead. -- RFC 1925