Main library-sandbox cross-build system

From IGSTK

Jump to: navigation, search

Contents


Motivation

On the tcon yesterday, we discussed the need for IGSTK main library-sandbox cross build system The main motivations behind such a build system are

  1. Expedite development and testing of new classes in the sandbox which require minor (light-weight) modification of the main library
  2. Enforce light-weight changes in the main library to pass thorugh the regular review process


Suggested Implementation

To implement this scheme, we will be using cmake language capability. The envisaged implementation is as follows

  1. IGSTK subdirectory will be created in the Sandbox
  2. The developer who is interesed in making minor modifications to a particular file in the main library, will make a copy this file to the IGSTK subdirectory.
  3. CMake file in the sandbox is modified so that
    1. The build system checks if there are any files in the IGSTK sub-directory.
    2. If there are files in the IGSTK subdirectory, a new IGSTK library will be generated. To generate this new IGSTK main library
      1. All source files in the main library except the ones with new versions in the IGSTK sudirectory of the Sandbox and source files in the IGSTK subdirectory are used.
      2. If modified header files exist in the IGSTK subdirectory of the sandbox, then these modified header are included before the header files in the main library during compilation.
    3. If there are no files in the IGSTK subdirectory, the already-built IGSTK library will be used.

Comments by DG: Jan 15, 2006

What I originally envisioned was that the Sandbox would be a skeleton copy of the IGSTK repository.

This is how this alternate Sandbox approach could be made to work with CMake:

  1. The Sandbox would be a skeleton of IGSTK, meaning that it would be based on the directory structure of IGSTK
    1. The Sandbox would contain copies of whatever IGSTK source files are modified relative to the last IGSTK release.
    2. The Sandbox could also contain new source files or directories
    3. The Sandbox would contain copies of all IGSTK CMake files, some of which would be modified as necessary
  2. If CMake required a source file it would
    1. Check the Sandbox first
    2. Check the main repository if the file wasn't found in the Sandbox
  3. CMake would build a Sandboxed version of the IGSTK library

This approach would simplify things because:

  1. There wouldn't be a need for two libraries (Sandbox and IGSTK), instead the Sandbox would just build an IGSTK library that included all the modifications from the Sandbox.
  2. It would cut the number of directories in half. If the Sandbox contains an IGSTK directory as described above, then there will be two Source directories, two Testing directories, etc.
  3. Merges would be easier to accomplish, since each file in the Sandbox would have an exactly corresponding location in the IGSTK directory structure.

How does this cross-build system affect bug fix process?

If bug fixes are made on files not currently in the IGSTK subdirectory, then there will not be a change in the process. However, if bug fixes are made on files that are currently in the IGSTK subdirectory, then the developer who fixs bugs in the main library is responsible to make the corresponding changes to the version in the IGSTK subdirectory of the Sandbox.

How does this cross-build system affect code review process?

During our regular code review process for release, the new version of the IGSTK main library programs stored in the IGSTK subdirectory will be reviewed in addition to the new files in the sandbox.


Luis Comments : Let's use CVS

After reviewing the motivation for these changes, and the suggested implementation, it seems that we are trying to manually recreate the functionalities that are already provided by CVS mechanism of tagging and branching.

Our current process have the following CVS analogies:

Our Process CVS Process Characteristic
Sandbox Trunk very dynamic: receives new classes and new features
main IGSTK Branch very stable: only receive bug fixes


What we are suggesting to do in the sections above is:

  • To keep "multiple versions" of files, so that we can have
    • a stable version of the files
    • a dynamic, development version of the files
  • Hold different policies on the controls used when commiting code to each one of those version.

All these features, are exactly what CVS is for.

The trunk of a CVS repository is equivalent to our Sandbox, in the sense that it is the place where many changes occurr and where new features are introduced.

The tagged branches are the stable versions of the code, and only bug fixed are committed in them.

The CVS scripts that Andy created for enforcing the use of Bug numbers and Feature numbers at commit time, can be configured for acting different when the commit is done in a branch, and when the commit is done on the main trunk.

It is very informative to read Chapter 6 of the CVS Book:

"Open Source Development with CVS" http://cvsbook.red-bean.com/


The suggestion will be:

  1. Get rid of the Sandbox
  2. When releasing, do tagging and branching.
  3. The release branches become the "stable" version of IGSTK (what we now call the "main IGSTK")
  4. Development activity goes directly into the trunk of the IGSTK repository.
  5. When ready for the next release
    1. we compare the content of the trunk with the content of the previous release branch,
    2. Identify all the changes
    3. Schedule all the changes for code reviews
    4. Do fixes from the code reviews onto the trunk
  6. When we are satisfied with the changes, then we tag and branch again.
Retrieved from "http://public.kitware.com/IGSTKWIKI/index.php/Main_library-sandbox_cross-build_system"
Personal tools
TOOLBOX
LANGUAGES