Table of Contents
RPSL design philosophy
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:
a class in a developer library bar from an external module:
one class in bar from another class in bar:
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.
Table of Contents
Last modified: Wed Nov 23 00:43:11 EST 2005