Defining system dependencies

In this tutorial we learn how to use wrappers to define system dependencies.Indeed it is sometimes difficult or even meaningless to build some dependencies from scratch, for instance:

• if the dependency is intrinsically bound to the operating system in use, like for instance the posix libraries, it would be risky to replace it with a custom build of this library as many other libraries and programs use the system one.
• if the dependency is complex, like for instance the x11 libraries, it would be a pain to build it, it is far simpler to directly use the system version, even if it restricts usable versions to only the one supported by the operating system.

Furthermore, you sometime must use the system version of a dependency, simply because it is used by another system dependency.

Combining all these concerns together we need a way to define external package dependencies either only or also as a system dependency. In the following sections we show how to define system dependencies (i.e. external packages directly provided by target platform) using wrappers.

First example: wrapper for posix system dependency

As a first example we will see how a dependency to posix libraries is written. Here we consider the term posix as the name of an external package that defines a the set of standard libraries in a posix compliant system : libdl, librt, etc.

Deploy the posix wrapper

cd <pid-worskspace>
pid deploy package=posix version=system

This will given no spectacular result, this is normal. Now let’s inspect the content of the wrapper:

cd <pid-worskspace>/wrappers/posix

The global CMakeLists.txt is defined as usual (see previous tutorials on wrappers).

You can see that inside the src folder of the wrapper there is a system folder but no version folder. This is normal since we define no PID built version of posix because we always use it as a system dependency.

Inside the system folder there are 2 files:

• a CMakeLists.txt file that describes the requirements on system configuration.
• a file named eval_posix.cmake that is the CMake script used to evaluate if the target platform

Let’s now inspect these two files.

File CMakeLists.txt

The content of this file should be more or less:

PID_Wrapper_System_Configuration(
    EVAL          eval_posix.cmake
		VARIABLES     LINK_OPTIONS		LIBRARY_DIRS 		RPATH   		INCLUDE_DIRS
		VALUES 		    POSIX_LINKS			POSIX_LIBDIRS		POSIX_LIBS 	POSIX_INCS
  )

# constraints
PID_Wrapper_System_Configuration_Constraints(IN_BINARY  soname
																		         VALUE 	    POSIX_SONAME)

PID_Wrapper_System_Configuration_Dependencies(threads)

As you can, see there is a specific API to describe requirements on system configuration (we call this description system configuration for short).

Global declaration

PID_Wrapper_System_Configuration is mandatory, it defines global information on system configuration.

• EVAL defines the path (relative to the system folder) to the evaluation file, here eval_posix.cmake. This argument is mandatory.
• VARIABLES argument lists variables generated by the configuration. Each of this variable is prefix with the name of the configuration, here posix. posix configuration so generates: posix_LINK_OPTIONS, posix_LIBRARY_DIRS, posix_RPATH and posix_INCLUDE_DIRS.
• VALUES argument lists the internal variables used to set the value of returned variables. Each variable in VALUES define the value of the returned variable at same place in VARIABLES. For instance POSIX_LINKS variable matches posix_LINK_OPTIONS variable.

We decide to normalize names of variables returned by configurations check. Even if all configurations are not forced to return them all, we suggest to defined them anytime possible:

• <config>_VERSION: is version of the configuration.
• <config>_LINK_OPTIONS: is the list of linker flags (-l...) to use when using the configuration.
• <config>_LIBRARY_DIRS: is the list of path to folders where system libraries binaries can be found.
• <config>_INCLUDE_DIRS: is the list of path to folders where system libraries headers can be found.
• <config>_COMPILER_OPTIONS: is the list of extra compiler options to use when building a project that uses the configuration.
• <config>_RPATH: is the list of path to runtime objects (typically .so files) in use when using the configuration.

User can decide to define additionnal variables depending on the needs of the configuration they have to define. The difference is that standard variables can be automatically deduced andd used when a dependency between a component and a configuation is defined.

The primary goal of system configurations is so to provide CMake variables that can be used into packages description, exactly as “classical” find modules in CMake.

Defining constraints

System configurations can also define constraints using PID_Wrapper_System_Configuration_Constraints function. Constraints are like additional arguments used when checking if target platform fulfills a platform configuration.

Constrainst can be of one of thos 3 types:

• REQUIRED: the constraint must be defined anytime the configuration is checked. It means that the parameter will be used inside the eval script (see next sections) to check additional properties of the configuration. The corresponding contraint is always propagated to expressions generated by the configuration (for instance in the description of a binary package).
• OPTIONAL: the constraint can be defined or not anytime the configuration is checked. It means that, if this contraint is specified, the corresponding parameter will be used inside the evaluation script (see next sections) to check additional properties of the configuration. The corresponding contraint is never propagated to expressions generated by the configuration (for instance in the description of a binary package).
• IN_BINARY: the constraint is optional at the moment the configuration is checked BUT is always propagated to expressions generated by the configuration (for instance in the description of a binary package).

Any kind and number of arguments can be defined for a configuration, but there are some standardized constraints:

• soname specifies the list of sonames of libraries provided by the configuration.
• symbol specifies the list of symbols and symbols’ versions provided by libraries of the configuration. Each symbol is defined usinhg the pattern <symbol_name,symbol_version>.
• version specifies the version of the package.

Those specific constraints are all IN_BINARY. The configuration’s find script does not need to handle soname and symbol explicitly. PID internal mechanism uses this information to check binary compatiblity. If specified, version constraint is used in the eval script to check that the given version is installed in system. It must have same value than <config>_VERSION variable returned to script.

In th example, evaluation of posix generate the soname of every library provided by the configuration. And this is obtained by reading the value of the POSIX_SONAME cmake variable. This variable must be set by the evak script (see next sections).

Dependencies

We can also define some dependencies between system configurations, this is achieved using PID_Wrapper_System_Configuration_Dependencies. The meaning is mostly the same as any dependency in PID: in the example posix depends on threads. This means that anytime the posix system configuration is evaluated the threads configuration will be evaluated as well. This later simply provides flags to use adequate threading libraries provided by the target platform operating system (it is based on the use of the well known FindThreads.cmake module).

File eval_posix.cmake

found_PID_Configuration(posix FALSE)
# - Find posix installation
# Try to find libraries for posix on UNIX systems. The following values are defined
#  posix_FOUND        - True if posix is available
#  posix_LIBRARIES    - link against these to use posix system
if (UNIX)

	# posix is never a framework and some header files may be
	# found in tcl on the mac
	set(CMAKE_FIND_FRAMEWORK_SAVE ${CMAKE_FIND_FRAMEWORK})
	set(CMAKE_FIND_FRAMEWORK NEVER)
	set(IS_FOUND TRUE)

	# check for headers
	if( CURRENT_PLATFORM_OS STREQUAL macos
		OR CURRENT_PLATFORM_OS STREQUAL freebsd)
		#posix libraries are in default system lib on BSD like systems
		set(POSIX_INCS)
		set(POSIX_SONAME)
		set(POSIX_LIBS)
		set(POSIX_LINKS)
		set(POSIX_LIBDIRS)
		found_PID_Configuration(posix TRUE)
	else() #linux based system

		find_path(posix_rt_INCLUDE_PATH time.h)
		find_path(posix_dl_INCLUDE_PATH dlfcn.h)

		if(NOT posix_rt_INCLUDE_PATH
			OR NOT posix_dl_INCLUDE_PATH)
			set(POSIX_INCS)
			set(IS_FOUND FALSE)
			message("[PID] ERROR : cannot find headers of posix libraries.")
		endif()

		# check for libraries (only in implicit system folders)
		find_PID_Library_In_Linker_Order(rt IMPLICIT rt_LIBRARY_PATH rt_SONAME)
		if(NOT rt_LIBRARY_PATH)
			message("[PID] ERROR : when finding posix, cannot find rt library.")
			set(IS_FOUND FALSE)
		endif()
		find_PID_Library_In_Linker_Order(dl IMPLICIT dl_LIBRARY_PATH dl_SONAME)
		if(NOT dl_LIBRARY_PATH)
			message("[PID] ERROR : when finding posix, cannot find dl library.")
			set(IS_FOUND FALSE)
		endif()

		if(IS_FOUND)
			set(POSIX_INCS ${posix_rt_INCLUDE_PATH} ${posix_dl_INCLUDE_PATH})
			set(POSIX_SONAME ${rt_SONAME} ${dl_SONAME})
			set(POSIX_LIBS ${rt_LIBRARY_PATH} ${dl_LIBRARY_PATH})
			found_PID_Configuration(posix TRUE)
			convert_PID_Libraries_Into_System_Links(POSIX_LIBS POSIX_LINKS)#getting good system links (with -l)
			convert_PID_Libraries_Into_Library_Directories(POSIX_LIBS POSIX_LIBDIRS)
			#SONAMES are already computed no need to use dedicated functions
		endif ()

		unset(posix_rt_INCLUDE_PATH CACHE)
		unset(posix_dl_INCLUDE_PATH CACHE)
		unset(IS_FOUND)
	endif()

	set(CMAKE_FIND_FRAMEWORK ${CMAKE_FIND_FRAMEWORK_SAVE})
endif ()

Evaluation files (let’s call them “eval files” for short) are used:

• to evaluate if the target platform fulfills the requirements, something like a classical find module in CMake. It mostly consists in finding adequate files (libraries, headers, executable) on target platform.
• to manage constraints defined in global description. In the example there is only the constraint soname that is specific and does not require to be managed into the script.
• to generate CMake variables that will be used to set value or variables declared in global description, either in returned variables, constraints or even dependencies. For instance it set the value of POSIX_INCS and POSIX_SONAME.

To write those files, PID provides a specific API that implements most of redundant operations, and common CMake command can also be used. Let’s now take a look at the code:

found_PID_Configuration(posix FALSE)
if (UNIX)
  # all code goes here
endif()

The first line is really common and simply sets the result of the script to false by default. Then we use classical CMake construct to determine if we are on a UNIX compliant OS. If not (e.g. on Windows) then the posix system configruation is never satisfied, which is a normal situation.

The remaining part if the code consist in finding libraries rt and dl:

...
if( CURRENT_PLATFORM_OS STREQUAL macos
  OR CURRENT_PLATFORM_OS STREQUAL freebsd)
  #posix libraries are in default system lib on BSD like systems
  set(POSIX_INCS)
  set(POSIX_SONAME)
  set(POSIX_LIBS)
  set(POSIX_LINKS)
  set(POSIX_LIBDIRS)
  found_PID_Configuration(posix TRUE)
else() #linux based system
 #linux code goes here
endif()
...

On MacOS and FreeBSD, those libraries are directly put into the system library so no need to detect them, and so there is no additionnal flag to provide to compiler and linker. That is why all variables are set to an empty value. The line found_PID_Configuration(posix TRUE) simply tells that system configuration is satisfied (which is always true by definition on those platforms). So main part of the implementation is for linux systems.

...
#linux based system
find_path(posix_rt_INCLUDE_PATH time.h)
find_path(posix_dl_INCLUDE_PATH dlfcn.h)

if(NOT posix_rt_INCLUDE_PATH
 OR NOT posix_dl_INCLUDE_PATH)
 set(POSIX_INCS)
 set(IS_FOUND FALSE)
 message("[PID] ERROR : cannot find headers of posix libraries.")
endif()

# check for libraries (only in implicit system folders)
find_PID_Library_In_Linker_Order(rt IMPLICIT rt_LIBRARY_PATH rt_SONAME)
if(NOT rt_LIBRARY_PATH)
 message("[PID] ERROR : when finding posix, cannot find rt library.")
 set(IS_FOUND FALSE)
endif()
...

Linux specific code looks like what we can find in CMake Find modules:

• we try to find the headers of the libraries using find_path CMake commands.
• we then try to find libraries binaries. We use find_PID_Library_In_Linker_Order rather than find_library because this utility finds a system library in system folders the same way as the linker will do. It also gives the soname of a library in addition to its canonical path on filesystem. In other work it automate the job.

Remark: the variable POSIX_SONAME must contain the soname of each library provided by the wrapper, so the script must set this variable with the sonames previously extracted from libraries binaries.

if(IS_FOUND)
  set(POSIX_INCS ${posix_rt_INCLUDE_PATH} ${posix_dl_INCLUDE_PATH})
  set(POSIX_SONAME ${rt_SONAME} ${dl_SONAME})
  set(POSIX_LIBS ${rt_LIBRARY_PATH} ${dl_LIBRARY_PATH})
  found_PID_Configuration(posix TRUE)
  convert_PID_Libraries_Into_System_Links(POSIX_LIBS POSIX_LINKS)#getting good system links (with -l)
  convert_PID_Libraries_Into_Library_Directories(POSIX_LIBS POSIX_LIBDIRS)
  #SONAMES are already computed no need to use dedicated functions
endif ()

Finally, if everything has been found then this means the system configuration is satisfied, so we can set the local variables that are used in global description to set all values and global variables.

• variables holding include directories, path to libraries and sonames can be directly set from previous operations.
• found_PID_Configuration(posix TRUE) is used to say that evaluation is successful.
• Other local variables that have not been already set (POSIX_LINKS and POSIX_LIBDIRS) thay can be deduced using convert_PID_Libraries_Into_System_Links and convert_PID_Libraries_Into_Library_Directories:
  • convert_PID_Libraries_Into_System_Links: convert path to libraries into their equivalent system link. For a library with name <name> it generates -l<name> from /usr/lib/lib<name>.so).
  • convert_PID_Libraries_Into_Library_Directories: get the path to the folders containing the libraries. For the variable containing the value /usr/lib/lib<name>.so it returns the variable containing /usr/lib.

Evaluate the posix system configuration

Now the description is complete, we can evaluate if the target platform fulfills the requirements of the posix system configuration. This is made in two steps:

cd <pid-workspace>/wrappers/posix
pid gen_system_check

This first command generates all the scripts and stuff used to evaluate the system configuration but does not perform the evaluation by itself. It must be used anytime you modify the description of posix. Then:

pid eval_system_check

This performs the evaluation of the system configuration on target platform, and gives the resulting output. Something like:

Built target gen_system_check
[PID] INFO : Evaluation of posix system configuration SUCCEEDED
 --- Returned variables ---
- posix_LINK_OPTIONS = -lrt-2.23;-ldl-2.23
- posix_LIBRARY_DIRS =
- posix_RPATH = /lib/x86_64-linux-gnu/librt-2.23.so;/lib/x86_64-linux-gnu/libdl-2.23.so
- posix_INCLUDE_DIRS = /usr/include;/usr/include
 --- Final contraints in binary ---
- soname=librt.so.1,libdl.so.2
Built target eval_system_check

This output is the same as the one used in check_PID_Platform command of packages. Locally, the eval_system_check command is only useful for debugging purpose. You may notice that library directories (posix_LIBRARY_DIRS) is empty which is normal since the library dir of posix libraries is in default library system path, so we do not need to set it in compilation process.

That’s it you know all the basics for writing system configuration checks in wrappers.

Second example: wrapper for boost system dependency

Now let’s talk about os variants of external packages. Sometimes we need an external package that we can build to be explicitly used as an OS variant. This means that a given version of the package must be installed from system packages and not locally built.

For instance, we may use a system configuration for a given external package for which we do not provide a build procedure, like for ROS, and this external package requires the system version of another exetrnal package for which we provide a build procedure. As an example we sometimes use ROS for some packages and we did not want to rebuild ROS so we never provided a build procedure for any of its versions. In the end we only provide a system configuration for ROS and all ROS dependencies are themselves system dependencies. ROS uses boost so we need boost to be managed as a system dependency as well.

In this tutorial we will write the system configuration for boost. We want to be able to use directly boost as a system dependency instead of dependency built within PID.

Deploy the boost wrapper

Let’s first deploy the wrapper for boost.

cd <pid-worskspace>
pid deploy package=boost version=system
cd <pid-worskspace>/wrappers/boost

File CMakeLists.txt

The content of this file should be more or less:

PID_Wrapper_System_Configuration(
		APT           libboost-dev
    PACMAN        boost
    EVAL          eval_boost.cmake
    FIND_PACKAGES Boost
    VARIABLES     VERSION 			LIBRARY_DIRS 				INCLUDE_DIRS 				RPATH						LINK_OPTIONS	COMPONENTS
		VALUES 		    BOOST_VERSION BOOST_LIBRARY_DIRS 	Boost_INCLUDE_DIRS 	Boost_LIBRARIES	BOOST_LINKS		BOOST_COMPONENTS
  )

# constraints
PID_Wrapper_System_Configuration_Constraints(
		OPTIONAL  version
		IN_BINARY libraries         soname            version
		VALUE 		BOOST_COMPONENTS  BOOST_SONAMES     BOOST_VERSION
)

PID_Wrapper_System_Configuration_Dependencies(posix)

As you can see the content has mostly same information as for the posix system configuration. But there are new informations:

In PID_Wrapper_System_Configuration:

• There are automatic install procedures defined for the boost package. They are defined using the name of the system packager detected at workspace level. Here two install procedures are defined : one for systems supporting apt packaging (debian derivatives), another for systems supporting pacman packages (archlinux derivatives). If after a first evaluation the system configuration is not satisfied by target platform and host is target platform, they the adequate system manager will be used to install system packages satisfying the dependency.
• Additional find files can be provided using the FIND_PACKAGES argument. Here we simply say that the find module named FindBoost.cmake is in the src/system folder.
• the variable VERSION is set. This is mandatory if you want PID to be capable of “translating” your system dependency as if if were a normal dependency in PID. To make it possible the version found must be the same as one of the versions defined in the boost wrapper: this is mandatory to make PID capable of defining components.

In PID_Wrapper_System_Configuration_Constraints the version is also set from same value, to enforce the use of corresponding boost version in binary. Indeed after boost has been found, its version has been deduced, and we need to force teh usage of this version in binary objects so we give to the version constraint the value BOOST_VERSION (a variable supposed to hold the version of boost).

In PID_Wrapper_System_Configuration_Dependencies we simply tell that boost configuration check requires posix configuration check to be satisfied first.

About constraints

You can see constraints as parameters to be used when checking a configuration (either from wrappers of native packages). So for instance you may want a package using a precise version of boost:

check_PID_Platform(CONFIGURATION boost[version=1.58.0])

version is a constraint IN_BINARY which means that it is optional at source level but mandatory in resulting binaries.

• Constaints are listed inside the [] characters just after configuration name.
• Each constraint as the form name=value where value may be a single value or a list. If a list is used all elements are separated by , characters.
• Constraints are separated with : symbol.

If in addition to previous constraint we also wanted to check for specific components:

check_PID_Platform(CONFIGURATION boost[version=1.58.0:libraries=serialization,thread,timer])

Since the two possible constraints specified are IN_BINARY such kind of expression will be used in resulting binary package description.

File eval_boost.cmake

Now that the “interface” of the system configuration is defined we need to write its behavior and this is achieved by the eval_boost.cmake file:

found_PID_Configuration(boost FALSE)
set(components_to_search system filesystem ${boost_libraries})#boost_libraries used to check that components that user wants trully exist

set(Boost_NO_BOOST_CMAKE ON)#avoid using CMake boost configuration file

if(boost_version)
	find_package(Boost ${boost_version} REQUIRED EXACT QUIET COMPONENTS ${components_to_search})
else()
	find_package(Boost REQUIRED QUIET COMPONENTS ${components_to_search})
endif()

if(Boost_FOUND)
	#if code goes here it means the required components have been found

	#Boost_LIBRARIES only contains libraries that have been queried, which is not sufficient to manage external package as SYSTEM in a clean way
	#Need to get all binary libraries depending on the version, anytime boost is found ! Search them from location Boost_LIBRARY_DIRS
	foreach(dir IN LISTS Boost_LIBRARY_DIRS)
		file(GLOB libs RELATIVE ${dir} "${dir}/libboost_*")
		if(libs)
			list(APPEND ALL_LIBS ${libs})
		endif()
	endforeach()
	set(ALL_BOOST_COMPS)
	foreach(lib IN LISTS ALL_LIBS)
		if(lib MATCHES "^libboost_([^.]+)\\..*$")
			list(APPEND ALL_BOOST_COMPS ${CMAKE_MATCH_1})
		endif()
	endforeach()
	list(REMOVE_DUPLICATES ALL_BOOST_COMPS)

	set(BOOST_VERSION ${Boost_MAJOR_VERSION}.${Boost_MINOR_VERSION}.${Boost_SUBMINOR_VERSION}) #version has been detected
	#Now relaunch the find script with the given components, to populate variables
	find_package(Boost ${BOOST_VERSION} EXACT REQUIRED QUIET COMPONENTS ${ALL_BOOST_COMPS})

	#if code goes here everything has been found correctly
	set(BOOST_COMPONENTS ${ALL_BOOST_COMPS})
	convert_PID_Libraries_Into_System_Links(Boost_LIBRARIES BOOST_LINKS)#getting good system links (with -l)
	convert_PID_Libraries_Into_Library_Directories(Boost_LIBRARIES BOOST_LIBRARY_DIRS)
	extract_Soname_From_PID_Libraries(Boost_LIBRARIES BOOST_SONAMES)
	found_PID_Configuration(boost TRUE)
endif()

Since we defined the constraint libraries and version, the eval script must be capable of configuring the find process depending on the value of those constraints. So we need a way to access values of these constraints in the find script. Hopefully PID automatically generates adequate variables for all constraints anytime needed. These CMake variables are named following the pattern <wrapper>_<constraint> and are used the classic way in CMake:

...
set(components_to_search system filesystem ${boost_libraries})#boost_libraries used to check that components that user wants trully exist

set(Boost_NO_BOOST_CMAKE ON)#avoid using CMake boost configuration file

if(boost_version)
	find_package(Boost ${boost_version} REQUIRED EXACT QUIET COMPONENTS ${components_to_search})
else()
	find_package(Boost REQUIRED QUIET COMPONENTS ${components_to_search})
endif()
...

We manipulate two variables:

• boost_libraries that is the variable representing the constraint libraries.
• boost_version that is the variable representing the constraint version.

As you may see the eval script will behave slightly differently depending on the value of those variables:

• if a version constraint is defined then the script checks if this version is found in system, and if not found the check will fail. If version is not used then any OS installed version is eligible.
• if a libraries constraint is defined then the find script checks that these component (in addition to default components system and filesystem) exist and collect their data. If any component specified does not exist the check will fail.

Remark: the call to find_package refers to the find module provided by the wrapper. Indeed those find modules have priority over those provided by CMake.

On important aspect in this script is that we set the value of the variable BOOST_VERSION. This variable will be used, as described before to set values of variables returned by system configuration evaluation (i.e. boost_VERSION).

Other parts of the code follow more or less the same logic as previously explained in posix wrapper:

• Boost_LIBRARIES variable is provided by the original eval script of boost. We use convert_PID_Libraries_Into_System_Links and convert_PID_Libraries_Into_Library_Directories commands to easily get BOOST_LINKS and BOOST_LIBRARY_DIRS internal variables.
• BOOST_COMPONENTS contains all libraries of Boost found on system.
• boost configuration check is successful when execution reaches the line found_PID_Configuration(boost TRUE).

All those internal variables will be used to set returned variables defined in check_boost.cmake, for instance:

• boost_INCLUDE_DIRS returned variable will be set from Boost_INCLUDE_DIRS (take care about CAPITAL letters) that has been generated by original project find module.
• BOOST_COMPONENTS (respectively BOOST_VERSION) is used to set the value of the libraries (respectively version) constraint in binary packages using the boost configuration.

Remark: the API that is used to write eval (or install) scripts is provided by the cmake file Configuration_Definition.cmake.

Evaluate the boost system configuration

cd <pid-workspace>/wrappers/boost/build
pid gen_system_check
pid eval_system_check

If everything went well, the result should look like:

[PID] INFO : Evaluation of boost system configuration SUCCEEDED
 --- Returned variables ---
- boost_VERSION = 1.58.0
- boost_LIBRARY_DIRS =
- boost_INCLUDE_DIRS = /usr/include
- boost_RPATH = /usr/lib/x86_64-linux-gnu/libboost_atomic.so;/usr/lib/x86_64-linux-gnu/libboost_chrono.so;/usr/lib/x86_64-linux-gnu/libboost_context.so;/usr/lib/x86_64-linux-gnu/libboost_coroutine.so;/usr/lib/x86_64-linux-gnu/libboost_date_time.so;/usr/lib/x86_64-linux-gnu/libboost_exception.a;/usr/lib/x86_64-linux-gnu/libboost_filesystem.so;/usr/lib/x86_64-linux-gnu/libboost_graph.so;/usr/lib/x86_64-linux-gnu/libboost_graph_parallel.so;/usr/lib/x86_64-linux-gnu/libboost_iostreams.so;/usr/lib/x86_64-linux-gnu/libboost_locale.so;/usr/lib/x86_64-linux-gnu/libboost_log.so;/usr/lib/x86_64-linux-gnu/libboost_log_setup.so;/usr/lib/x86_64-linux-gnu/libboost_math_c99.so;/usr/lib/x86_64-linux-gnu/libboost_math_c99f.so;/usr/lib/x86_64-linux-gnu/libboost_math_c99l.so;/usr/lib/x86_64-linux-gnu/libboost_math_tr1.so;/usr/lib/x86_64-linux-gnu/libboost_math_tr1f.so;/usr/lib/x86_64-linux-gnu/libboost_math_tr1l.so;/usr/lib/x86_64-linux-gnu/libboost_mpi.so;/usr/lib/x86_64-linux-gnu/libboost_mpi_python-py27.so;/usr/lib/x86_64-linux-gnu/libboost_mpi_python-py35.so;/usr/lib/x86_64-linux-gnu/libboost_mpi_python.so;/usr/lib/x86_64-linux-gnu/libboost_prg_exec_monitor.so;/usr/lib/x86_64-linux-gnu/libboost_program_options.so;/usr/lib/x86_64-linux-gnu/libboost_python-py27.so;/usr/lib/x86_64-linux-gnu/libboost_python-py35.so;/usr/lib/x86_64-linux-gnu/libboost_python.so;/usr/lib/x86_64-linux-gnu/libboost_random.so;/usr/lib/x86_64-linux-gnu/libboost_regex.so;/usr/lib/x86_64-linux-gnu/libboost_serialization.so;/usr/lib/x86_64-linux-gnu/libboost_signals.so;/usr/lib/x86_64-linux-gnu/libboost_system.so;/usr/lib/x86_64-linux-gnu/libboost_test_exec_monitor.a;/usr/lib/x86_64-linux-gnu/libboost_thread.so;/usr/lib/x86_64-linux-gnu/libboost_timer.so;/usr/lib/x86_64-linux-gnu/libboost_unit_test_framework.so;/usr/lib/x86_64-linux-gnu/libboost_wave.so;/usr/lib/x86_64-linux-gnu/libboost_wserialization.so
- boost_LINK_OPTIONS = -lboost_atomic;-lboost_chrono;-lboost_context;-lboost_coroutine;-lboost_date_time;-lboost_exception.a;-lboost_filesystem;-lboost_graph;-lboost_graph_parallel;-lboost_iostreams;-lboost_locale;-lboost_log;-lboost_log_setup;-lboost_math_c99;-lboost_math_c99f;-lboost_math_c99l;-lboost_math_tr1;-lboost_math_tr1f;-lboost_math_tr1l;-lboost_mpi;-lboost_mpi_python-py27;-lboost_mpi_python-py35;-lboost_mpi_python;-lboost_prg_exec_monitor;-lboost_program_options;-lboost_python-py27;-lboost_python-py35;-lboost_python;-lboost_random;-lboost_regex;-lboost_serialization;-lboost_signals;-lboost_system;-lboost_test_exec_monitor.a;-lboost_thread;-lboost_timer;-lboost_unit_test_framework;-lboost_wave;-lboost_wserialization
- boost_COMPONENTS = atomic;chrono;context;coroutine;date_time;exception;filesystem;graph;graph_parallel;iostreams;locale;log;log_setup;math_c99;math_c99f;math_c99l;math_tr1;math_tr1f;math_tr1l;mpi;mpi_python-py27;mpi_python-py35;mpi_python;prg_exec_monitor;program_options;python-py27;python-py35;python;random;regex;serialization;signals;system;test_exec_monitor;thread;timer;unit_test_framework;wave;wserialization
 --- Final contraints in binary ---
- libraries=atomic,chrono,context,coroutine,date_time,exception,filesystem,graph,graph_parallel,iostreams,locale,log,log_setup,math_c99,math_c99f,math_c99l,math_tr1,math_tr1f,math_tr1l,mpi,mpi_python-py27,mpi_python-py35,mpi_python,prg_exec_monitor,program_options,python-py27,python-py35,python,random,regex,serialization,signals,system,test_exec_monitor,thread,timer,unit_test_framework,wave,wserialization
- soname=libboost_atomic.so.1.58.0,libboost_chrono.so.1.58.0,libboost_context.so.1.58.0,libboost_coroutine.so.1.58.0,libboost_date_time.so.1.58.0,libboost_filesystem.so.1.58.0,libboost_graph.so.1.58.0,libboost_graph_parallel.so.1.58.0,libboost_iostreams.so.1.58.0,libboost_locale.so.1.58.0,libboost_log.so.1.58.0,libboost_log_setup.so.1.58.0,libboost_math_c99.so.1.58.0,libboost_math_c99f.so.1.58.0,libboost_math_c99l.so.1.58.0,libboost_math_tr1.so.1.58.0,libboost_math_tr1f.so.1.58.0,libboost_math_tr1l.so.1.58.0,libboost_mpi.so.1.58.0,libboost_mpi_python-py27.so.1.58.0,libboost_mpi_python-py35.so.1.58.0,libboost_prg_exec_monitor.so.1.58.0,libboost_program_options.so.1.58.0,libboost_python-py27.so.1.58.0,libboost_python-py35.so.1.58.0,libboost_random.so.1.58.0,libboost_regex.so.1.58.0,libboost_serialization.so.1.58.0,libboost_signals.so.1.58.0,libboost_system.so.1.58.0,libboost_thread.so.1.58.0,libboost_timer.so.1.58.0,libboost_unit_test_framework.so.1.58.0,libboost_wave.so.1.58.0,libboost_wserialization.so.1.58.0
- version=1.58.0

Create a new system configuration

Creating a new system configuration (let’s say my-config) starts by :

• creating the corresponding wrapper

cd <pid-workspace>
pid create wrapper=my-config

• or reusing an existing wrapper if you already specified install procedures for the corresponding external package.

From a global point of view, the process is exactly the same as for defining any wrapper. You just have to add a system folder where you need to write:

• the CMakeLists.txt defining the system configuration.
• an eval file (referenced by the CMakeLists.txt) that tells how to check if target platform fufills the corresponding system configuration. Reference the evaluation file using EVAL argument of PID_Wrapper_System_Configuration.
• optionally define which system packages have to be installed, using appropriate keyword for the host possible packaging systems (you can use one or more argument whose names match those of the packaging system : ÀPT, PACMAN, YUM, BREW, PORT, CHOCO).
• optionally you can specify an install file (using INSTALL argument of PID_Wrapper_System_Configuration) if the install procedure is too complex to simply require the installation of a set of packages depending on the packaging system in use. This script is called instead of a direct call to system package manager.
• optionally add find modules into the folder for each things you may want to fing using find_package. Reference the modules using FIND_PACKAGES argument of PID_Wrapper_System_Configuration.
• optionally add any kind of content (files and folder) that are required by the evaluation script. Reference this content using ADDITIONAL_CONTENT argument of PID_Wrapper_System_Configuration