Commit 9629e2fe authored by Manuel Grizonnet's avatar Manuel Grizonnet

Merge branch 'develop' into...

Merge branch 'develop' into 1672-linux-self-extracting-binary-does-not-install-correctly-on-debian-stretch
parents fcaec9d1 64690304
We are ready to release OTB version MAJOR.MINOR.PATCH. The following steps need to be done:
### 1. Branches
* [ ] **(if major or minor release)** Feature freeze: [create the new release branch](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/wikis/Help-for-release-actions#create-release-branch)
* [ ] **(if patch release)** Work on the already existing branch `release-MAJOR-MINOR`
* [ ] Make sure the version number in `CMakeLists.txt` is MAJOR.MINOR.PATCH
### 2. Housekeeping
* [ ] In this story, make a list of blocking issues for the release (if any)
* [ ] [Update dashboard scripts](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/wikis/Help-for-release-actions#dashboard) to support new version numbers
* [ ] [Update the SuperBuild archive](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/wikis/Help-for-release-actions#superbuild-archive) (if needed)
* [ ] Update release notes (walk the GitLab MR merged history and log all improvements)
* [ ] Update the date in RELEASE_NOTES.txt
* [ ] Run Debian [spelling](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/wikis/Help-for-release-actions#spelling-check) checker
* [ ] Run shellcheck script from [OTB-Devutils/Scripts/](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb-devutils/blob/master/Scripts/run_shellcheck.sh)
* [ ] [Update translation](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/wikis/Help-for-release-actions#translation-for-monteverdi-mapla) for Monteverdi and Mapla
* [ ] [Sanity check the binary packages](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/wikis/Help-for-release-actions#standalone-packages-sanity-check)
* [ ] Windows
* [ ] Linux
* [ ] Mac
### 3. Actual release
Once all blocking issues are closed, and the previous steps are done:
* [ ] [Tag the release or RC](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/wikis/Help-for-release-actions#release-tag)
* [ ] **(if major or minor release)**: Merge the release into develop
* [ ] **(if it's the latest release)**: Merge the release into master
* [ ] **(if patch release)**: Backport fixes
* [ ] Update GIT_TAG for all official remote modules (if needed)
### 4. Publish and plan next release
* [ ] [Prepare and upload source packages](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/wikis/Help-for-release-actions#prepare-and-upload-source-packages)
* [ ] [Promote nightly packages](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/wikis/Help-for-release-actions#promote-nightly-packages)
* [ ] [Update documentation](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/wikis/Help-for-release-actions#update-documentation)
* [ ] Software Guide
* [ ] Cookbook
* [ ] Doxygen
* [ ] Application online documentation
* [ ] WordPress page "Home" and "Download" pages
* [ ] Upload OTB source archive to [Zenodo](https://zenodo.org/) to create a unique Digital Object Identifier (DOI)
* [ ] Update OTB-Data-Examples.tgz on orfeo-toolbox (packages)
* [ ] Send email to mailing list to announce the release
* [ ] Release announcement on the blog
* [ ] Announcement on social networks (twitter, google+)
* [ ] Forward announcement to news_item@osgeo.org ([OSGeo news](https://www.osgeo.org/foundation-news/))
* [ ] Plan the next release (nominate new release manager, setup PSC meeting on IRC)
* [ ] Contact QGis processing plugin maintainer to update XML description for new OTB-Applications (or [supply it](https://wiki.orfeo-toolbox.org/index.php/QGIS_access_to_OTB_applications#updating-the-XML-descriptors))
* [ ] Remove public branches related to MR or bugfix merged before the release
/label ~story
......@@ -117,8 +117,6 @@ macro(otb_create_application)
list(REMOVE_DUPLICATES OTB_APPLICATIONS_NAME_LIST)
set(OTB_APPLICATIONS_NAME_LIST ${OTB_APPLICATIONS_NAME_LIST}
CACHE STRING "List of all applications" FORCE)
mark_as_advanced(OTB_APPLICATIONS_NAME_LIST)
endmacro()
macro(otb_test_application)
......
......@@ -23,7 +23,8 @@ cmake_minimum_required(VERSION 3.1.0)
foreach(p
CMP0025 # CMake 3.0
CMP0042 # CMake 3.0
CMP0058
CMP0058 # CMake 3.3
CMP0072 # CMake 3.11
)
if(POLICY ${p})
cmake_policy(SET ${p} NEW)
......@@ -91,6 +92,8 @@ if( CMAKE_HOST_WIN32 )
endif()
endif()
set(OTB_APPLICATIONS_NAME_LIST "" CACHE STRING "List of all applications" FORCE)
mark_as_advanced(OTB_APPLICATIONS_NAME_LIST)
set(OTB_CMAKE_DIR ${OTB_SOURCE_DIR}/CMake)
set(CMAKE_MODULE_PATH ${OTB_CMAKE_DIR} ${CMAKE_MODULE_PATH})
......
......@@ -177,3 +177,21 @@ Regarding labels, we use the following set:
* ~"To Do": action is planned
* ~Doing: work in progress
* ~api ~app ~documentation ~monteverdi ~packaging ~qgis: optional context information
## Versioning
Starting from OTB 7.0.0, we use [semantic versioning](https://semver.org/). See the website for the full spec, in summary:
> Given a version number MAJOR.MINOR.PATCH, increment the:
>
> 1. MAJOR version when you make incompatible API changes,
> 2. MINOR version when you add functionality in a backwards-compatible manner, and
> 3. PATCH version when you make backwards-compatible bug fixes.
>
> Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.
The develop branch is always the place where the upcoming major or minor release is worked on. Patch releases are done on release branches, for example 7.0.1 and 7.0.2 could be found on the release-7.0 branch.
For the purpose of defining backwards compatibility, the OTB API covers (not an exhaustive list): the C++ API, the Python bindings, application names, application parameters, output format and interpretation of input data.
When we deprecate part of our public API, we should do two things: (1) update our documentation to let users know about the change, (2) issue a new minor or major release with the deprecation in place.
......@@ -16,16 +16,6 @@ A simple example is given below:
#include "otbBandMathImageFilterX.h"
#include "otbVectorImage.h"
int otbBandMathImageFilterXNew( int itkNotUsed(argc), char* itkNotUsed(argv) [])
{
typedef double PixelType;
typedef otb::VectorImage<PixelType, 2> ImageType;
typedef otb::BandMathImageFilterX<ImageType> FilterType;
FilterType::Pointer filter = FilterType::New();
return EXIT_SUCCESS;
}
As we can see, the new band math filter works with the class
otb::VectorImage.
......
......@@ -16,9 +16,10 @@ Conrad Bielski (JRC),
Cyrille Valladeau (CS),
Daniel McInerney,
David Dubois,
David Youssefi (CNES Intern, then CS),
David Youssefi (CNES Intern, then CS, then CNES),
Edouard Barthelet (Telecom Bretagne and Thales Communications),
Emmanuel Christophe (CNES, then CRISP, then Google),
Emmanuelle Sarrazin (CNES),
Etienne Bougoin (CS),
Gr\'egoire Mercier (Telecom Bretagne),
Guillaume Borrut (CS),
......@@ -33,7 +34,7 @@ Julien Malik (CS),
Julien Michel (CS then CNES),
Julien Osman,
Julien Radoux (UCL),
Laurentiu Nicola (CS Romania),
Laurentiu Nicola (CS ROMANIA),
Luc Hermitte (CS),
Ludovic Hussonnois (CS),
Manuel Grizonnet (CNES),
......
......@@ -157,19 +157,15 @@ The header files contain class declarations
and formatted comments that are used by the Doxygen documentation
system to automatically produce HTML manual pages.
In addition to class headers, there are a few other important header files.
In addition to class headers, there are a few other important ITK header files.
\begin{description}
\item[\code{itkMacro.h}] is found in the
\code{Utilities/ITK/Code/Common} directory
and defines standard system-wide macros (such as \code{Set/Get},
\item[\code{itkMacro.h}] defines standard system-wide macros (such as \code{Set/Get},
constants, and other parameters).
\item[\code{itkNumericTraits.h}] is found in the \code{Utilities/ITK/Code/Common}
directory and defines numeric characteristics for native types such
\item[\code{itkNumericTraits.h}] defines numeric characteristics for native types such
as its maximum and minimum possible values.
\item[\code{itkWin32Header.h}] is found in the \code{Utilities/ITK/Code/Common}
and is used to define operating system parameters to control
\item[\code{itkWin32Header.h}] is used to define operating system parameters to control
the compilation process.
\end{description}
......@@ -215,7 +211,7 @@ In practice object factories are used mainly (and generally transparently) by
the OTB input/output (IO) classes. For most users the greatest impact is on
the use of the \code{New()} method to create a class. Generally the
\code{New()} method is declared and implemented via the macro
\code{itkNewMacro()} found in \code{Utilities/ITK/Common/itkMacro.h}.
\code{itkNewMacro()} found in \code{Modules/Core/Common/include/itkMacro.h}.
\subsection{Smart Pointers and Memory Management}
......
\chapter{Adding New Modules}
\label{chapter:newModules}
This chapter is concerned with the creation of new modules.
This chapter is concerned with the creation of new modules.
The following sections give precise instructions about :
\begin{itemize}
\item the organization of your directories
......@@ -14,20 +14,20 @@ The following sections give precise instructions about :
\label{sec:writemodule}
There is a template of OTB remote module which help you start developing you're
remote module: \href{https://github.com/orfeotoolbox/otbExternalModuleTemplate}{External Module Template}
remote module: \href{https://gitlab.orfeo-toolbox.org/remote_modules/remote-module-template}{External Module Template}
Each module is made of different components, which are described in the following sections.
\section{The otb-module.cmake file}
This file is mandatory. It follows the CMake syntax, and has two purposes:
This file is mandatory. It follows the CMake syntax, and has two purposes:
\begin{itemize}
\item Declare dependencies to other modules,
\item Provide a short description of the module purpose.
\item Declare dependencies to other modules,
\item Provide a short description of the module purpose.
\end{itemize}
These purposes are fulfilled by a single CMake Macro call:
These purposes are fulfilled by a single CMake Macro call:
\begin{verbatim}
otb_module(TheModuleName DEPENDS OTBModule1 OTBModule2 ... OTBModuleN DESCRIPTION "A description string")
......@@ -38,13 +38,13 @@ otb_module(TheModuleName DEPENDS OTBModule1 OTBModule2 ... OTBModuleN DESCRIPTIO
\section{The CMakeLists.txt file}
The CMakeLists.txt file is mandatory. It contains only a few things.
First, it declares a new CMake project with the name of the module.
First, it declares a new CMake project with the name of the module.
\begin{verbatim}
project(TheModuleName)
\end{verbatim}
Second, if the module contain a library (see src folder section below), it initializes the TheModuleName\textunderscore LIBRARIES CMake variable (if your module only contains headers or template code, skip this line):
Second, if the module contain a library (see src folder section below), it initializes the TheModuleName\textunderscore LIBRARIES CMake variable (if your module only contains headers or template code, skip this line):
\begin{verbatim}
set(TheModuleName_LIBRARIES OTBTheModuleName)
......@@ -52,7 +52,7 @@ set(TheModuleName_LIBRARIES OTBTheModuleName)
You can build your remote modules inside the OTB source tree by copying your
source inside the directory \textit{Module/Remote} or against an existing OTB
build tree (note that it does not work with an install version of OTB).
build tree (note that it does not work with an install version of OTB).
The configuration below will handle both cases and take care of all the CMake
plumbing of the module:
......@@ -68,7 +68,7 @@ plumbing of the module:
\end{verbatim}
The overall file should look like this:
\begin{verbatim}
cmake_minimum_required(VERSION 2.8.9)
project(TheModuleName)
......@@ -85,14 +85,14 @@ if(NOT OTB_SOURCE_DIR)
\section{The include folder}
The include folder will contain all your headers (*.h files) and template method boy files (*.hxx or *.hxx). It does not require any additional file (in particular, no CMakeLists.txt file is required).
The include folder will contain all your headers (*.h files) and template method boy files (*.hxx or *.hxx). It does not require any additional file (in particular, no CMakeLists.txt file is required).
\section{The src folder }
The src folder contains the internal implementation of your module :
The src folder contains the internal implementation of your module :
\begin{itemize}
\item It typically contains cxx source files that will be compiled into a library.
\item It typically contains cxx source files that will be compiled into a library.
\item It can contain header files for classes used only within the implementation files of your module. Any header file present in the src folder will not be installed, and will not be available to other modules depending on your module.
\end{itemize}
......@@ -100,7 +100,7 @@ If your modules is made of template only code, you do not need a src folder at a
If present, the src folder requires a CMakeLists.txt file.
The first part of the CMakeLists.txt file is classical, as it builds the library and links it:
The first part of the CMakeLists.txt file is classical, as it builds the library and links it:
\begin{verbatim}
set(OTBTheModuleName_SRC
......@@ -115,19 +115,19 @@ add_library(OTBTheModuleName ${OTBTheModuleName_SRC})
target_link_libraries(OTBTheModuleName ${OTBModule1_LIBRARIES} ${OTBModule2_LIBRARIES} ... ${OTBModuleN_LIBRARIES})
\end{verbatim}
\textbf{Notes}:
\textbf{Notes}:
\begin{itemize}
\item Library name should match the one declared in the root CMakeLists.txt when setting CMake variable TheModuleName\textunderscore LIBRARIES,
\item Linked libraries should match the dependencies of your module declared in the root otb-module.cmake file.
\item Library name should match the one declared in the root CMakeLists.txt when setting CMake variable TheModuleName\textunderscore LIBRARIES,
\item Linked libraries should match the dependencies of your module declared in the root otb-module.cmake file.
\end{itemize}
The last line of CMake code takes care of installation instructions:
The last line of CMake code takes care of installation instructions:
\begin{verbatim}
otb_module_target(TBTheModuleName)
\end{verbatim}
The overall CMakeLists.txt file should look like:
The overall CMakeLists.txt file should look like:
\begin{verbatim}
set(OTBTheModuleName_SRC
......@@ -152,14 +152,14 @@ The app folder contains the code of applications shipped with your module. If yo
In addition to the applications source code, the app folder should contain a CMakeLists.txt file as follows.
For each application, a single call otb\textunderscore create\textunderscore application is required:
For each application, a single call otb\textunderscore create\textunderscore application is required:
\begin{verbatim}
otb_create_application(
NAME TheModuleApplication1
SOURCES TheModuleApplication1.cxx
LINK_LIBRARIES ${OTBModule1_LIBRARIES} ${OTBModule2_LIBRARIES} ... ${OTBModuleN_LIBRARIES})
\end{verbatim}
\section{The test folder}
......@@ -168,13 +168,13 @@ This folder contains tests of the module. If your module has no test in it (whic
The test folder should contain the source files of tests, as well as a CMakeLists.txt file. This file will contain the following.
First, indicate that this folder contains tests.
First, indicate that this folder contains tests.
\begin{verbatim}
otb_module_test()
\end{verbatim}
Then, build the test driver:
Then, build the test driver:
\begin{verbatim}
set(OTBTheModuleNameTests
......@@ -186,11 +186,11 @@ set(OTBTheModuleNameTests
add_executable(otbTheModuleNameTestDriver ${OTBTheModuleNameTests})
target_link_libraries(otbTheModuleNameTestDriver ${OTBTheModuleName-Test_LIBRARIES})
otb_module_target_label(otbTheModuleNameTestDriver)
\end{verbatim}
Finally, you can add your tests:
Finally, you can add your tests: