It is usually quite easy to adapt existing code to follow the pods guidlines
This is especially true if the existing build system is already configured to install things to the system path.
In such cases, it is usually sufficient to do the following:
This task is made even easier by the Makefile provided by the [PodsTool]. For cmake based projects it is often sufficient to just add this Makefile to the top level directory. Otherwise one can modify it accordingly fairly easily.
In addition, there is are a set of functions provided in pods.cmake which enable:
Automatic setup/handling of necessary paths and destinations.
Simple generation of pkg-config files which specify the compilation, link, and include flags for the libraries in your pods.
"Easy to do the most common things, possible to do others"
If you don't have write/commit access to a code-base that you'd like to be a pod, it is easy to create a "wrapper-pod". This is usually done by creating a pod with Makefile that runs the build system for the legacy code with all the options set appropriately. The external code-base can then by linked in via SVN:Externals.
If the external code-base doesn't have an appropriate install target, the Makefile for the wrapper pod can manually copy out the headers, libraries, and binaries to the appropriate location in the BUILD_PREFIX directory.
Wiki: CorePolicy
Wiki: PodsTool
Anonymous