Here are some C++ library design considerations and how RPSL addresses them.


Development should be easy
The developer's time is the most valuable single element of a project.  The goal
of RPSL is to automate all aspects of development except writing code. The 
developer never touches any type of build file and organization is natural.  
External dependencies are specified in one small, ascii file.


Source code should be standardized and conventional
The main investment in any project is in the source code.  For reuse the 
source code layout and content should be conventional and independent of 
the build system. With RPSL, source code has no "flavor" and can be moved 
easily to other build systems such as native autotools, Eclipse managed 
make and bjam.

With RPSL, the source code headers use the standard #ifdef wrapper to prevent
multiple inclusions.  Modern compilers now cache this information so that 
there is no compile time impact with multiple includes.

Header include directives are done using the widely-accepted form:

a system library:
     #include <iostream>       

a class in a developer library bar from an external module:
     #include <bar/barClass.h> 

one class in bar from another class in bar:
     #include <bar/barClass.h> 
or
     #include <barClass.h> 

RPSL also automatically generates a library module API header that includes 
all other headers in the library:
     #include <bar/bar.h>       // entire API for "bar"

This "include everything" header is useful and practical because RPSL 
libraries are small.  There is also a provision for the developer to specify 
what will be available in the API.  This defines the pulic library API where
some classes are for library-only implementation use and should not be 
visible to the user of the library.


Recompile time for small changes should be fast
The intent is for RPSL libraries to be small - five to 20 classes.  This means
even a full rebuild will be fast.  Partial rebuilds are supported by the 
Makefile dependency system exploited by the autotools.  With shared object 
targets a rebuild doesn't even require relinking the executable.


Flexibility should exist to support special cases
For many of the generated files the user can locally override the usual
result in a persistent way. A second level of source heirarchy provides for
such things as file-specific compiler flags if needed.


All aspects of the system should be free and open source but permit any
license for source code and binaries
RSPSL is a platform-independent set of bash scripts that exploit the GNU
autotools and pkg-config.  All of this is open source and under the GPL.
Because, of course, the build system doesn't get compiled into executables, 
neither RPSL nor the autotools or pkg-config prevent a resulting binary from 
being proprietary. As stated earlier the source that works with RSPL can be 
completely divorced from it and distributed with any license and any other
build system at any time now or in the future.

top