Script for generating the binary builds of Stereo Pipeline
Python CMake Shell Other



A. Stereo Pipeline

The NASA Ames Stereo Pipeline (ASP) is a suite of free and open source
automated geodesy and stereogrammetry tools designed for processing
planetary and Earth imagery captured from satellites and robotic
rovers. It produces cartographic products, including digital elevation
models (DEMs), ortho-projected imagery, and 3D models. These data
products are suitable for science analysis, mission planning, and
public outreach.

B. Binary Builder

The Binary Builder is a collection of scripts for building the release
binaries for the NASA Ames Stereo Pipeline (ASP). Binary Builder
downloads and builds all dependencies of ASP including the
dependencies of Vision Workbench and USGS's Integrated Software for
Imagers and Spectrometers (ISIS).

Building release binaries is a very difficult and fragile
process. Never can we guarantee that this code works as it will break
on changes made by our dependencies. This code will break on server
URL changes, build system changes, and just generally unsupported
environments. You use this software at your own risk.


A. Copyright and License Summary

Copyright (c) 2009-2012, United States Government as represented by
the Administrator of the National Aeronautics and Space
Administration. All rights reserved.

ASP is licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License. You
may obtain a copy of the License at

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
implied. See the License for the specific language governing
permissions and limitations under the License.


A. Produce a Complete Binary Build

If you would like Binary Builder to create a tarball of all Stereo
Pipeline binaries and dependencies, you can use the following

  source ./auto_build/
 ./ last-completed-run/install

It is pretty likely that things will break. This is essentially a
fragile package manager. When things break you'll probably want to
keep calling the build command to see if you fixed the
problem. Traditionally will just build everything, here's how
to rebuild one specific package (that presumably failed):

 ./ --resume gdal

We strongly encourage you to read the output from ./ --help and
./ --help. There are more features not talked about here.

B. Produce a Partial Build or Dev Environment

We usually like to build the dependencies once and then build the
release binaries with every ASP release. Here's how to build the
dependencies as an archive tarball:

 ./ --build-goal 1
 ./ --include all --set-name BaseSystem last-completed-run/install

Then, when you are ready to build the ASP release tarballs:

 ./ --base BaseSystem-*.tar.bz2 visionworkbench stereopipeline
 ./ last-completed-run/install

However, if you just want to call and build VW and ASP yourself so
that you can modify the code, instead of the last two commands use:

 ./ BaseSystem-*.tar.bz2 <INSTALL DIR for 3rd Party software>

Inside the <INSTALL DIR> that you specified you'll find the
appropriate 'bin' and 'lib' directories for all of the used third
party libraries. You will also find example config.option files for VW
and ASP. Copy those files into your respective directories for VW and
ASP. Then you can build VW. Modify the config.options for ASP so that
it points to where VW is.

C. Produce a VW only build

BinaryBuilder now supports the option to build only for Vision Workbench,
saving the time of building the extensive libraries needed only for ASP.
These options work similarly to the ASP methods described above.

For a complete VW build, run with the argument: --build-goal 2

For a VW only development environment, run with the argument: --build-goal 3

Other than using these flag values you can use the and tools
in the same manner as if building ASP.


The list of packages that were already built is stored in
<build-root>/done.txt (default: ./build_asp/done.txt). On each line is
the package name and the hash tag for that package. To force a package
to be rebuilt, remove its entry from the list. A package will be
rebuilt in either case if the hash tag changes.

To avoid building a package even if it was not built yet, invoke with the option _<package name>, i.e., ./ _isis.