Add and document a Dockerfile or some easy way to get started with OTB development
What changes will be made and why they would make a better Orfeo ToolBox?
High level description
SuperBuild is neat, however it doesn't always work because of issues in some of the dependencies (!239 (merged)) or other reasons (#1718, #1719 (closed)). And not using it is awkward, as some dependencies (OSSIM, ITK, OpenThreads, libsvm) aren't available on all distributions. ITK tends to be problematic on rolling distros because VNL hard-codes a list of compiler versions, which isn't kept up to date. GCC 8.1 was released in May 2018, while ITK 4.13.1 with support for it came out in August.
This is a proposal to add a sanctioned configuration (OS and dependencies) suitable for OTB development, together with some description of how to get started. Docker can be used to set up a reproducible environment; the source code and build directory can be mounted as volumes, so the user can edit the source in whatever editor or IDE they prefer, while building in the container. Of course, fancy IDE features like "go to definition" will not work, because the dependencies are not available on the host.
The advantages of using Docker instead of a VM are that:
- one doesn't have to spend time setting it up
- on Linux, it has better performance than a VM
As a minimal straw-man proposal, we could start from an Ubuntu Bionic image with the following additions:
apt install libgeotiff-dev cmake cmake-curses-gui libinsighttoolkit4-dev libgdal-dev libboost-dev libopenthreads-dev libossim-dev libtinyxml-dev libsvm-dev
Risks and benefits
- benefit: it makes it possible to work on OTB on rolling distros
- benefit: getting familiar with Docker could help some developers investigate issues on distros they don't normally have access to
- benefit: it gives users a separate development environment, so they don't have to clutter their systems with the OTB dependencies. For example, when uninstalled, one of the Arch OSSIM packages (IIRC) removes the
/lib, rendering the system unbootable after the next kernel update.
- risk: some people might be unhappy with what's in the Docker image (e.g. should it include
- risk: if we only include a
Dockerfile(a short description of how to build the container image), people might expect the image to be available on Dockerhub (so they can just download instead of building it) or a run-time image, and that might increase the maintenance effort
- risk: the
Dockerfilemight need to be updated from time to time (on distro or OTB releases with dependency changes, e.g. if OSSIM is dropped, it should be removed from the
Dockerfile); this is an additional maintenance effort, albeit small
- risk: developing Monteverdi might not work or need additional setup
- risk: doing this is a silent acknowledgement that OTB isn't as portable as we might like it to be
Alternatives for implementations
- do nothing: there aren't a lot of OTB developers, and most of them are probably using one of the Dashboard platforms, so they don't run into issues
- add a line in the documentation/Wiki: "To get started on Ubuntu 18.04, install these packages: ..."; this might be the easiest solution
- test on rolling releases and patch the dependencies: e.g. we could have patched SuperBuild ITK to add support for GCC 8 long before ITK 4.13.1 came out; this would some churn and maintenance effort as well, at the benefit of supporting more systems
- reuse: refer users to an existing Docker image (UbuntuGIS?) that might have the dependencies already available.
Who will be developing the proposed changes?
@lnicola, or up for grabs.