Wrapper API

PID_Wrapper

PID_Wrapper(AUTHOR ... YEAR ... LICENSE ... DESCRIPTION ... [OPTIONS])
declare_PID_Wrapper(AUTHOR ... YEAR ... LICENSE ... DESCRIPTION ... [OPTIONS])
Declare the current CMake project as a PID wrapper for a given external package with specific meta-information passed as parameter.

Required parameters

AUTHOR <name>:Defines the name of the reference author.
YEAR <dates>:Reflects the lifetime of the wrapper, e.g. YYYY-ZZZZ where YYYY is the creation year and ZZZZ the latest modification date.
LICENSE <license name>:
 The name of the license applying to the wrapper. This must match one of the existing license file in the licenses directory of the workspace. This license applies to the wrapper and not to the original project.
DESCRIPTION <description>:
 A short description of the package usage and utility.

Optional parameters

INSTITUTION <institutions>:
 Define the institution(s) to which the reference author belongs.
MAIL <e-mail>:E-mail of the reference author.
ADDRESS <url>:The url of the wrapper’s official repository. Must be set once the package is published.
PUBLIC_ADDRESS <url>:
 Can be used to provide a public counterpart to the repository ADDRESS
README <path relative to share folder>:
 Used to define a user-defined README file for the package.

Constraints

  • This function must be called in the root CMakeLists.txt file of the wrapper before any other call to the PID Wrapper API.
  • It must be called exactly once.

Effects

Initialization of the wrapper’s internal state. After this call the its content can be defined.

Example

PID_Wrapper(
  AUTHOR Robin Passama
  INSTITUTION LIRMM
  YEAR 2013
  LICENSE CeCILL-C
  ADDRESS git@gite.lirmm.fr:passama/a-given-wrapper.git
  DESCRIPTION "an example PID wrapper"
)

PID_Original_Project

PID_Original_Project(AUTHORS ... LICENSE ... URL ...)
define_PID_Wrapper_Original_Project_Info(AUTHORS ... LICENSE ... URL ...)
Set the meta information about original project being wrapped by current project.

Required parameters

AUTHORS <string>:
 Defines who are the authors of the original project.
LICENSE <string>:
 The license that applies to the original project content.
URL <url>:this is the index URL of the original project.

Constraints

  • This function must be called in the root CMakeLists.txt file of the wrapper, after declare_PID_Wrapper.
  • It must be called exactly once.

Effects

Sets the meta-information about original project.

Example

PID_Original_Project(
   AUTHORS "Boost.org contributors"
   LICENSES "Boost license"
   URL http://www.boost.org)

PID_Wrapper_Author

PID_Wrapper_Author(AUTHOR ... [INSTITUTION ...])
add_PID_Wrapper_Author(AUTHOR ... [INSTITUTION ...])
Add an author to the list of authors of the wrapper.

Required parameters

[AUTHOR] <string>:
 Name of the author. The keyword AUTHOR can be avoided if the name is given as first argument.

Optional parameters

INSTITUTION <institutions>:
 the institution(s) to which the author belongs.

Constraints

  • This function must be called in the root CMakeLists.txt file of the package, after declare_PID_Wrapper and before build_PID_Wrapper.

Effects

Add another author to the list of authors of the wrapper.

Example

PID_Wrapper_Author(AUTHOR Another Writter INSTITUTION LIRMM)

PID_Wrapper_Category

PID_Wrapper_Category(...)
add_PID_Wrapper_Category(...)
Declare that the current wrapper generates external packages that belong to a given category.

Required parameters

<string>:Name of the category

Constraints

  • This function must be called in the root CMakeLists.txt file of the wrapper, after declare_PID_Wrapper and before build_PID_Wrapper.

Effects

Register the wrapper has being member of the given (sub)category. This information will be added to the wrapper reference file when it is generated.

Example

PID_Wrapper_Category(example/packaging)

PID_Wrapper_Option

PID_Wrapper_Option(OPTION ... TYPE ... DEFAULT ... [DESCRIPTION ...])
define_PID_Wrapper_User_Option(OPTION ... TYPE ... DEFAULT ... [DESCRIPTION ...])
Declare that the current wrapper generates external packages that belong to a given category.

Required parameters

[OPTION] <name>:
 string defining the name of the user option. This name can then be used in deployment scripts. The option keyword can be omitted is name is given as first argument.
TYPE <type of the cmake option>:
 type of the option, to be chosen between: FILEPATH (File chooser dialog), PATH (Directory chooser dialog), STRING (Arbitrary string), BOOL.
DEFAULT …:Default value for the option.

Optional parameters

DESCRIPTION <string>:
 a string describing what this option is acting on.

Constraints

  • This function must be called in the root CMakeLists.txt file of the wrapper, after declare_PID_Wrapper and before build_PID_Wrapper.

Effects

Register a new user option into the wrapper. This user option will be used only in deployment scripts.

Example

PID_Wrapper_Option(OPTION BUILD_WITH_CUDA_SUPPORT
  TYPE BOOL DEFAULT OFF
  DESCRIPTION "set to ON to enable CUDA support during build")

PID_Wrapper_Publishing

PID_Wrapper_Publishing(PROJECT ... GIT|FRAMEWORK ... [OPTIONS])
declare_PID_Wrapper_Publishing(PROJECT ... GIT|FRAMEWORK ... [OPTIONS])
Declare that the current wrapper generates external packages that belong to a given category.

Required parameters

PROJECT <url>:This argument tells where to fing the official repository project page of the wrapper. This is used to reference the wrapper project into the static site.

Optional parameters

ALLOWED_PLATFORMS <list of platforms>:
 This argument limits the set of platforms used for CI, only platforms specified will be managed in the CI process. WARNING: Due to gitlab limitation (only one pipeline can be defined) only ONE platform is allowed at the moment.
DESCRIPTION <string>:
 This is a long(er) description of the wrapper that will be used for its documentation in static site.
PUBLISH_BINARIES:
 If this argument is used then the wrapper will automatically publish new binary versions to the publication site.
FRAMEWORK <name of the framework>:
 If this argument is set, then it means that the wrapper belongs to a framework. It will so contribute to the framework site. You must use either this argument or GIT one.
GIT <repository address>:
 This is the address of the lone static site repository for the wrapper. It is used to automatically clone/update the static site of the wrapper. With this option the wrapper will not contribute to a framework but will have its own isolated deployment. You must use either this argument or FRAMEWORK one.
PAGE <url>:This is the online URL of the static site index page. Must be used if you use the GIT argument.

Constraints

  • This function must be called in the root CMakeLists.txt of the package, after declare_PID_Wrapper and before build_PID_Wrapper.
  • This function must be called it has to be called after any other following functions: add_PID_Wrapper_Author, add_PID_Wrapper_Category and define_PID_Wrapper_Original_Project_Info.

Effects

  • Generate or update a static site for the project. This static site locally resides in a dedicated git repository. If the project belongs to no framework then it has its lone static site that can be found in <pid-workspace>/sites/packages/<wrapper name>. If it belongs to a framework, the framework repository can be found in <pid-workspace>/sites/frameworks/<framework name>. In this later case, the wrapper only contributes to its own related content not the overall content of the framework.
  • Depending on options it can also deploy binaries for target platform into the static site repository (framework or lone static site).

Example

PID_Wrapper_Publishing(
  PROJECT https://gite.lirmm.fr/pid/boost
  FRAMEWORK pid
  DESCRIPTION boost is a PID wrapper for external project called Boost. Boost provides many libraries and templates to ease development in C++.
  PUBLISH_BINARIES
  ALLOWED_PLATFORMS x86_64_linux_abi11)

build_PID_Wrapper

build_PID_Wrapper()
Configure the PID wrapper according to overall information.

Constraints

This function must be the last one called in the root CMakeList.txt file of the wrapper.

Effects

This function generates configuration files, manage the generation of the global build process and call CMakeLists.txt files of version folders contained in subfolder src.

Example

build_PID_Wrapper()

PID_Wrapper_Version

PID_Wrapper_Version(VERSION ... DEPLOY ... [OPTIONS])
add_PID_Wrapper_Known_Version(VERSION ... DEPLOY ... [OPTIONS])
Declare a new version of the original project wrapped into PID system.

Required parameters

[VERSION] <version string>:
 tells which version of the external package is being wrapped. The version number must exactly match the name of the folder containing the CMakeLists.txt that does this call. The keyword version may be omitted is version is the first argument.
DEPLOY <path to deploy script>:
 This is the path, relative to the current folder, to the deploy script used to build and install the external package version. Script must be a cmake module file.

Optional parameters

POSTINSTALL <path to install script>:
 This is the path, relative to the current folder, to the install script that will be run after external package version has been installed into the workspace, to perform additionnal configuration steps. Script is a cmake module file.
COMPATIBILITY <version number>:
 define which previous version is compatible with this current version, if any. Compatible simply means that this current version can be used instead of the previous one without any restriction.
SONAME <version number>:
 (useful on UNIX only) Specify which soname will be given by default to all shared libraries defined by the wrapper.

Constraints

  • This function must be the first one called in the CMakeList.txt file of a version folder.

Effects

Configure information about a specific version of the external package.

Example

PID_Wrapper_Version(VERSION 1.55.0 DEPLOY deploy.cmake
    SONAME 1.55.0 #define the extension name to use for shared objects
)

PID_Wrapper_Configuration

PID_Wrapper_Configuration(CONFIGURATION ... [PLATFORM ...])
declare_PID_Wrapper_Platform_Configuration(CONFIGURATION ... [PLATFORM ...])
Declare a platform configuration constraint for the current version of the external project being described.

Required parameters

CONFIGURATION <list of configurations>:
 tells which version of the external package is being wrapped. The version number must exactly match the name of the folder containing the CMakeLists.txt that does this call.

Optional parameters

PLATFORM <platform name>:
 Use to apply the configuration constraints only to the target platform.

Constraints

  • This function must be called in the CMakeList.txt file of a version folder after add_PID_Wrapper_Known_Version.

Effects

  • Configure the check of a set of platform configurations that will be perfomed when the given wrapper version is built.

Example

PID_Wrapper_Configuration(CONFIGURATION posix)

PID_Wrapper_Dependency

PID_Wrapper_Dependency([PACKAGE] ... [[EXACT] VERSION ...]...)
declare_PID_Wrapper_External_Dependency([PACKAGE] ... [[EXACT] VERSION ...]...)

Declare a dependency between the currently described version of the external package and another external package.

Required parameters

[PACKAGE] <string>:
 defines the unique identifier of the required package. The keyword PACKAGE may be omitted if name is the first argument.

Optional parameters

VERSION <version string>:
 dotted notation of a version, representing which version of the external package is required. May be use many times.
EXACT:use to specify if the following version must be exac. May be used for earch VERSION specification.
COMPONENTS <list of components>:
 Used to specify which components of the required external package will be used by local components. If not specified there will be no check for the presence of specific components in the required package.

Constraints

  • This function must be called in the CMakeList.txt file of a version folder after add_PID_Wrapper_Known_Version.

Effects

  • Register the target package as a dependency of the current package.

Example

PID_Wrapper_Dependency (PACKAGE boost EXACT VERSION 1.55.0 EXACT VERSION 1.63.0 EXACT VERSION 1.64.0)

PID_Wrapper_Component

PID_Wrapper_Component([COMPONENT] ... [OPTIONS])
declare_PID_Wrapper_Component([COMPONENT] ... [OPTIONS])

Declare a new component for the current version of the external package.

Required parameters

[COMPONENT] <string w/o withespaces>:
 defines the unique identifier of the component. The COMPONENT keyword may be omnitted if name if the first argument.

Optional parameters

C_STANDARD <number of standard>:
 This argument is followed by the version of the C language standard to be used to build this component. The values may be 90, 99 or 11.
CXX_STANDARD <number of standard>:
 This argument is followed by the version of the C++ language standard to be used to build this component. The values may be 98, 11, 14 or 17. If not specified the version 98 is used.
SONAME <version number>:
 This argument allows to set the SONAME to use for that specific library instead of the default one.
DEFINITIONS <defs>:
 These are the preprocessor definitions used in the component’s interface.
INCLUDES <folders>:
 These are the include folder to pass to any component using the current component. Path are interpreted relative to the installed external package version root folder.
SHARED_LINKS <links>:
 These are shared link flags. Path are interpreted relative to the installed external package version root folder.
STATIC_LINKS <links>:
 These are static link flags. Path are interpreted relative to the installed external package version root folder.
OPTIONS <compile options>:
 These are compiler options to be used whenever a third party code use this component. This should be used only for options bound to compiler usage, not definitions or include directories.
RUNTIME_RESOURCES <list of path>:
 This argument is followed by a list of path relative to the installed external package version root folder.
EXPORT …:list of components that are exported by the declared component. Each element has the pattern [<package name>/]<component_name>.
DEPEND …:list of components that the declared component depends on. Each element has the pattern [<package name>/]<component_name>.

Constraints

  • Must be called in the CMakeList.txt file of a version folder after add_PID_Wrapper_Known_Version and before any call to declare_PID_Wrapper_Component_Dependency applied to the same declared component.

Effects

  • Define a component for the current external package version, which is mainly usefull to register all compilation options relative to a component.

Example

PID_Wrapper_Component(COMPONENT libyaml INCLUDES include SHARED_LINKS ${posix_LINK_OPTIONS} lib/libyaml-cpp)

PID_Wrapper_Component_Dependency

PID_Wrapper_Component_Dependency([COMPONENT] ... [OPTIONS])
declare_PID_Wrapper_Component_Dependency([COMPONENT] ... [OPTIONS])

Declare a dependency for a component defined in the current version of the current external package.

Required parameters

[COMPONENT] <string w/o withespaces>:
 defines the unique identifier of the component for which a dependency is described. The keyword COMPONENT may be omitted if name is given as first argument.

Optional parameters

EXPORT:Tells whether the component exports the required dependency. Exporting means that the reference to the dependency is contained in its interface (header files). This can be only the case for libraries, not for applications.
DEPEND:Tells whether the component depends on but do not export the required dependency. Exporting means that the reference to the dependency is contained in its interface (header files).
[EXTERNAL] <dependency>:
 This is the name of the component whose component <name> depends on. EXTERNAL keyword may be omitted if EXPORT or DEPEND keyword are used.
PACKAGE <name>:This is the name of the external package the dependency belongs to. This package must have been defined has a package dependency before this call. If this argument is not used, the dependency belongs to the current package (i.e. internal dependency).
DEFINITIONS <definitions>:
 List of definitions exported by the component. These definitions are supposed to be managed in the dependency’s heaedr files, but are set by current component.
INCLUDES <list of path>:
 List of path to system include folders.
LIBRARY_DIRS <list of path>:
 List of path to system libraries folders.
SHARED_LINKS <list of link>:
 List of shared system links.
STATIC_LINKS <list of link>:
 List of static system links.
OPTIONS <list of options>:
 List of compiler options to use when using a system library.
RUNTIME_RESOURCES <list of path>:
 List of path to system runtime resource such as program for instance.
C_STANDARD <std number>:
 the C standard used by the dependency.
CXX_STANDARD <std number>:
 the C++ standard used by the dependency.

Constraints

  • Must be called in the CMakeList.txt file of a version folder after add_PID_Wrapper_Known_Version and after any call to declare_PID_Wrapper_Component applied to the same declared component.

Effects

  • Define and configure a dependency between a component in the current external package version and another component.

Example

PID_Wrapper_Component_Dependency(COMPONENT libyaml EXPORT EXTERNAL boost-headers PACKAGE boost)

Script functions

get_External_Dependencies_Info

get_External_Dependencies_Info([OPTIONS])

Allow to get info defined in description of the currenlty built version.

Optional parameters

PACKAGE <ext_package>:
 Target external package that is a dependency of the currently built package, for which we want specific information. Used as a filter to limit information to those relative to the dependency.
ROOT <variable>:
 The variable passed as argument will be filled with the path to the dependency external package version. Must be used together with PACKAGE.
OPTIONS <variable>:
 The variable passed as argument will be filled with compiler options for the external package version being built.
INCLUDES <variable>:
 The variable passed as argument will be filled with include folders for the external package version being built.
DEFINITIONS <variable>:
 The variable passed as argument will be filled with all definitions for the external package version being built.
LINKS <variable>:
 The variable passed as argument will be filled with all path to librairies and linker options for the external package version being built.
LIBRARY_DIRS <variable>:
 The variable passed as argument will be filled with all path to folders containing libraries.
C_STANDARD <variable>:
 The variable passed as argument will be filled with the C language standard to use for the external package version, if any specified.
CXX_STANDARD <variable>:
 The variable passed as argument will be filled with the CXX language standard to use for the external package version, if any specified.
RESOURCES <variable>:
 The variable passed as argument will be filled with the runtime resources provided by external dependencies.
FLAGS:option to get result of all preceeding arguments directly as compiler flags instead of CMake variables.

Constraints

  • Must be used in deploy scripts defined in a wrapper.

Effects

  • This function has no side effect but simply allow the wrapper build process to get some information about the package it is trying to build. Indeed, building an external package may require to have precise information about package description in order to use adequate compilation flags.

Example

Example of deploy script used for the yaml-cpp wrapper:

get_External_Dependencies_Info(INCLUDES all_includes)
execute_process(COMMAND ${CMAKE_COMMAND} -DBUILD_SHARED_LIBS=ON -DCMAKE_INSTALL_PREFIX=${TARGET_INSTALL_DIR} -DBoost_INCLUDE_DIR=${all_includes} .. WORKING_DIRECTORY ${YAML_BUILD_DIR})

get_User_Option_Info

get_User_Option_Info(OPTION ... RESULT ...)

Allow to get info defined and set by user of the wrapper into deploy script when a wrapper version is built.

Required parameters

OPTION <variable>:
 Target option we need to get the value into the deploy script.
RESULT <returned variable>:
 The variable passed as argument will be filled with the value of the target user option’s value.

Constraints

  • Must be used in deploy scripts defined in a wrapper.

Effects

  • This function has no side effect but simply allow the wrapper build process to get some information about the package it is trying to build. Indeed, building an external package may require additional configuration from the user in order to use adequate compilation flags.

Example

get_User_Option_Info(OPTION BUILD_WITH_CUDA_SUPPORT RESULT using_cuda)
if(using_cuda)
  build_process_using_CUDA(...)
else()
  build_process_without_CUDA(...)
endif()

get_Environment_Info

get_Environment_Info([JOBS ...] [MAKE...])
get_Environment_Info(C|CXX|ASM [RELEASE|DEBUG] [CFLAGS...] [COMPILER ...] [AR ...] [LINKER...] [RANLIB...])
get_Environment_Info(MODULE|SHARED|STATIC|EXE LDFLAGS...)

Getting all options and flags (compiler in use, basic flags for each type of component, and so on) defined by the current environment, to be able to access them in the deploy script.

Optional parameters

C|CXX|ASM:Specifies the type of information to get.
MODULE|SHARED|STATIC|EXE:
 Specifies the type of binary to link.
RELEASE|DEBUG:Used to specify which kind of flags you want (RELEASE by default)
CFLAGS …:the output variable that contains the list of compilation flags used for specified compilation (e.g. C and DEBUG)
LDFLAGS …:the output variable that contains the list of linker flags used for specified compilation (e.g. SHARED)
COMPILER <path>:
 the output variable that contains the path to the compiler used for specified compilation (e.g. C++ compiler)
AR <path>:the output variable that contains the path to the ar tool.
LINKER <path>:the output variable that contains the path to the linker.
RANLIB <path>:the output variable that contains the path to the ranlib tool.
JOBS flag:the output variable that contains the flag used for parallel build.
MAKE <path>:the output variable that contains the path to the make tool.

Constraints

  • Must be used in deploy scripts defined in a wrapper.

Effects

  • This function has no side effect but simply allow the wrapper build process to get some information about the package it is trying to build.

Example

get_Environment_Info(MAKE make_tool JOBS jobs-flag
                    CXX COMPILER compiler_used CFLAGS compile_flags
                    SHARED LDFLAGS linker_flags)

get_Target_Platform_Info

get_Target_Platform_Info([OPTIONS])

Get information about the target platform. This can be used to configure the build accordingly.

Optional parameters

All arguments are optional but at least one must be provided. All properties are retrieved for the target platform.

NAME <VAR>:Output the name of the target platform in VAR
TYPE <VAR>:Ouptut the processor type in VAR
OS <VAR>:Output the OS name in VAR
ARCH <VAR>:Output the architecture in VAR
ABI <VAR>:Output the ABI in VAR
DISTRIBUTION <VAR>:
 Output the distribution in VAR
VERSION <VAR>:Output the version of the distribution in VAR
PYTHON <VAR>:Output the Python version in VAR

Effects

After the call, the variables defined by the user will be set to the corresponding value. Then it can be used to control the configuration of the package.

Example

get_Target_Platform_Info(OS curr_os ARCH curr_proc ABI curr_abi TYPE curr_proc_type)
message("curr_os=${curr_os}")

install_External_Project

install_External_Project([URL ...] ARCHIVE|GIT_CLONE_COMMIT ... FOLDER ... PATH ... [OPTIONS])
Install the external project into build tree. This project can be either:
  • downloaded as an archive from an online archive filesystem
  • cloned from an online git repository
  • extracted from a local archive provided by the wrapper

Required parameters

ARCHIVE|GIT_CLONE_COMMIT <string>:
 The name of the archive downloaded (or its path relative to current source dir if not download) or the identifier of the commit to checkout to. Both keyword ARCHIVE and GIT_CLONE_COMMIT are exclusive.
FOLDER <string>:
 The folder resulting from archive extraction or repository cloning.

Optional parameters

URL <url>:The URL from where to download the archive.
PATH <path>:the output variable that contains the path to the installed project, empty if project cannot be installed
PROJECT <string>:
 the name of the project if you want to generate nice outputs about external package install process
VERSION <version string>:
 the version of the external project that is installed, only usefull together with PROJECT keyword.

Constraints

  • Must be used in deploy scripts defined in a wrapper.

Effects

  • This function is used to download and install the archive of an external project.

Example

install_External_Project( PROJECT yaml-cpp
                  VERSION 0.6.2
                  URL https://github.com/jbeder/yaml-cpp/archive/yaml-cpp-0.6.2.tar.gz
                  ARCHIVE yaml-cpp-0.6.2.tar.gz
                  FOLDER yaml-cpp-yaml-cpp-0.6.2)

return_External_Project_Error

return_External_Project_Error()

Make the current wrapper script to return an error.

Constraints

  • Must be used in deploy scripts defined in a wrapper.

Effects

  • generates an error code for the current deploy script.

Example

return_External_Project_Error()

build_B2_External_Project

build_B2_External_Project(PROJECT ... FOLDER ... MODE ... [OPTIONS])

Configure, build and install an external project defined with Boost build.

Required parameters

PROJECT <string>:
 The name of the external project.
FOLDER <string>:
 The name of the folder containing the project.
MODE <Release|Debug>:
 The build mode.

Optional parameters

QUIET:if used then the output of this command will be silent.
COMMENT <string>:
 A string to append to message to inform about special thing you are doing. Usefull if you intend to buildmultiple time the same external project with different options.
DEFINITIONS <list of definitions>:
 the CMake definitions you need to provide to the cmake build script.
WITH <list of libraries>:
 Libraries to be included in the build
WITHOUT <list of libraries>:
 Libraries to be excluded from the build

Constraints

  • Must be used in deploy scripts defined in a wrapper.

Effects

  • Build and install the external project into workspace install tree..

Example

build_B2_External_Project(PROJECT boost FOLDER boost_1_64_0 MODE Release)

build_Autotools_External_Project

build_Autotools_External_Project(PROJECT ... FOLDER ... MODE ... [OPTIONS])

Configure, build and install an external project defined with GNU autotools.

Required parameters

PROJECT <string>:
 The name of the external project.
FOLDER <string>:
 The name of the folder containing the project.
MODE <Release|Debug>:
 The build mode.

Optional parameters

QUIET:if used then the output of this command will be silent.
COMMENT <string>:
 A string to append to message to inform about special thing you are doing. Usefull if you intend to buildmultiple time the same external project with different options.
DEFINITIONS <list of definitions>:
 the CMake definitions you need to provide to the cmake build script.

Constraints

  • Must be used in deploy scripts defined in a wrapper.

Effects

  • Build and install the external project into workspace install tree..

Example

build_Autotools_External_Project(PROJECT aproject FOLDER a_project_v12 MODE Release)

build_Waf_External_Project

build_Waf_External_Project(PROJECT ... FOLDER ... MODE ... [OPTIONS])

Configure, build and install an external project defined with python Waf tool.

Required parameters

PROJECT <string>:
 The name of the external project.
FOLDER <string>:
 The name of the folder containing the project.
MODE <Release|Debug>:
 The build mode.

Optional parameters

QUIET:if used then the output of this command will be silent.
COMMENT <string>:
 A string to append to message to inform about special thing you are doing. Usefull if you intend to buildmultiple time the same external project with different options.
DEFINITIONS <list of definitions>:
 the CMake definitions you need to provide to the cmake build script.

Constraints

  • Must be used in deploy scripts defined in a wrapper.

Effects

  • Build and install the external project into workspace install tree..

Example

build_Waf_External_Project(PROJECT aproject FOLDER a_project_v12 MODE Release)

build_CMake_External_Project

build_CMake_External_Project(URL ... ARCHIVE ... FOLDER ... PATH ... [OPTIONS])

Configure, build and install a Cmake external project.

Required parameters

PROJECT <string>:
 The name of the external project.
FOLDER <string>:
 The name of the folder containing the project.
Mode <Release|Debug>:
 The build mode.

Optional parameters

QUIET:if used then the output of this command will be silent.
COMMENT <string>:
 A string to append to message to inform about special thing you are doing. Usefull if you intend to buildmultiple time the same external project with different options.
DEFINITIONS <list of definitions>:
 the CMake definitions you need to provide to the cmake build script.

Constraints

  • Must be used in deploy scripts defined in a wrapper.

Effects

  • Build and install the external project into workspace install tree..

Example

build_CMake_External_Project( PROJECT yaml-cpp FOLDER yaml-cpp-yaml-cpp-0.6.2 MODE Release
                      DEFINITIONS BUILD_GMOCK=OFF BUILD_GTEST=OFF BUILD_SHARED_LIBS=ON YAML_CPP_BUILD_TESTS=OFF YAML_CPP_BUILD_TESTS=OFF YAML_CPP_BUILD_TOOLS=OFF YAML_CPP_BUILD_CONTRIB=OFF gtest_force_shared_crt=OFF
                      COMMENT "shared libraries")

build_Bazel_External_Project

build_Bazel_External_Project(PROJECT ... FOLDER ... INSTALL_PATH ... MODE ... TARGET .. [OPTIONS])

Configure, build and install a Bazel (google build system) external project.

Required parameters

PROJECT <string>:
 The name of the external project.
FOLDER <string>:
 The name of the folder containing the project.
INSTALL_PATH <path>:
 The path where the components are supposed to be found
MODE <Release|Debug>:
 The build mode.
TARGET <string>:
 The name of the target being built.

Optional parameters

MIN_VERSION:minimum version of bazel tool to use.
MAX_VERSION:maximum version of bazel tool to use.
QUIET:if used then the output of this command will be silent.
COMMENT <string>:
 A string to append to message to inform about special thing you are doing. Usefull if you intend to buildmultiple time the same external project with different options.
DEFINITIONS <list of definitions>:
 the bazel definitions (environment variables) you need to provide to the cmake build script.

Constraints

  • Must be used in deploy scripts defined in a wrapper.

Effects

  • Build and install the external project into workspace install tree..

Example

build_Bazel_External_Project( PROJECT tensorflow FOLDER tensorflow-1.13.1 MODE Release
                      COMMENT "shared libraries")