Menu

AdaptingExistingCode Log in to Edit

Abe Bachrach

Adapting an Existing Code-Base

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:

  1. Add a Makefile in the top level directory that calls cmake/configure/rake/etc...
  2. Have the Makefile set the BUILD_PREFIX to the appropriate location according to the pods guidlines

Useful Tools

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"

Wrapper Pods

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.


Related

Wiki: CorePolicy
Wiki: PodsTool

Discussion

Anonymous
Anonymous

Add attachments
Cancel





Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.