Note: This post has been superseded by the pages at pile-contributors.github.io and does not reflect the current state of the project.
This post attempts to organize ideas related to code re-usability.
It mostly targets pieces of code too small to form a library
(but flexibility is added to create static or shared libraries).
We will refer to such a unit as a
pile consists of two repositories:
- one that only contains the source code, copyright information,
usage information, called
- one that contains everything else like test code, tools
used to generate the source, etc. called
pile is to be replaced by the actual name.
The tools to be used are CMake and git. The parameters that change the functionality are to be passed on using CMake, with the source being kept unchanged. Any change to the source should be passed upstream to improve the overall quality and usability.
pile uses CMake to generate content. The root directory of a
pile-source contains a
CMakeLists.txt file to allow including
pile as a normal directory and it also contains a
having a mandatory
CMakeLists.txt should only contain code specific for using the
as a normal library, either shared or static. All other functionality
is to be placed in
cmake/pile.cmake so that the user has the option
add_directory() or to include the macro file.
Git sub-modules are to be used extensively. Each
pile is intended
to become a git sub-module in the user's repository. To add a pile
git submodule add git://github.com/chneukirchen/rack.git rack
To clone a project with sub-modules one has to:
git clone --recursive git://github.com/schacon/myproject.git
Dependencies can either be added as nested sub-modules or siblings.
Second (and recommended) mode requires the user to provide the
dependencies explicitly. A call to
pileInit() before should suffice.
cmake/pile.cmake module is required to contain a macro named
pileDependencies() that in turn defines
PILES_DEPENDENCIES as a