This chapter describes the operating systems and compilers supported by Boost.Process. It also includes some guidelines on how to port the code to a new platform or a different Boost.Build toolset.
Boost.Process supports several different operating systems. Based on their programming API and process management models, they can be classified in two major platforms:
These systems follow the POSIX process model and use standard APIs to manage child processes. Simply put all processes are organized based on a parent/child relationship and applications start new processes by using the
execve pair of system calls. This separation allows the child process to perform extra operations before executing the real target. Systems in this group include all Unix-like operating systems.
Even though these systems support some of the POSIX system calls in the standard C Runtime library (CRT), they have a completely different process management model. Processes are spawned using a single system call known as
CreateProcess which receives all the configuration parameters for the new child.
Knowing how to classify the supported operating systems, the following table lists all operating systems known to support Boost.Process (according to the test suite):
|Operating system name||API type||API constant|
|Mac OS X 10.4.x||POSIX||BOOST_POSIX_API|
|NetBSD 3.x and 4.x||POSIX||BOOST_POSIX_API|
The third column in the table above mentions the name of a preprocessor constant defined by the header filer
boost/process/config.hpp based on the platform type. Code using the library can use that constant to determine the platform it is running under.
Please note that the list above is not exhaustive. It is highly possible that Boost.Process works fine under other, unlisted operating systems because many of them are just variations of the above. Shall you try and use Boost.Process successfully on any other platform, please tell us so that it can be added to the list.
The Boost.Build compilation system abstracts compilers in what are known as toolsets. A toolset interacts with a specific compiler and linker to build the library and associated utilities (test suite, documentation and examples) in a platform-independent way, freeing the application developer from knowing the specific build details of the underlying platform.
Toolsets are specific to the operating systems they run under; e.g. the msvc toolset (Microsoft Visual C++) is not available under a GNU/Linux system. Therefore they should not be considered on their own but, for simplicity reasons, the table below lists the supported toolsets only.
|Toolset name||Specific versions|
|darwin||GCC 3.3 and 4.0 as shipped with XCode 2.3|
|gcc||GCC 3.x and 4.x|
|msvc||Microsoft Visual Studio 2005/2008|
A very important design goal of Boost.Process was to achieve maximum portability. It is certainly possible to adapt the library to new operating systems and compilers, generally with minimum efforts. However, porting to a new platform might be an extremely complex task, specially if its process management model differs from that of POSIX and Windows platforms.
Let's start with the easy task: porting to a new compiler. The library itself does not use any compiler-specific construction in its code so it should not cause problems. However, old compilers can raise errors if they do not support some of the ANSI C++ features. If this happens, the problem should be worked around in the simplest possible way.
A different issue is the test suite. The test suite builds a helper binary utility used by many other tests. These tests need to know where the helper binary is located and to do so they use some conditionals based on the toolset name. (Ideally Boost.Build could provide the real path to the code, but this feature is not available.) As you can imagine, this will surely cause problems when adopting a new toolset because it will not be recognized by the path determination machinery. In order to fix this you must adapt the
get_helpers_path function in
libs/process/test/misc.hpp to recognize the helper's binary location when built with the new toolset.
In order to port the library to a new operating system, you must first check that
boost/process/config.hpp is determining the appropriate platform type for it. Once this is done, it should be a matter of running the test suite, detecting any build problems that may arise and fixing them appropriately. Remember that if the new operating system conforms to one of the supported platforms, it should behave similarly and not require big changes to the code.
In a different order of magnitude is the task to port the library to a new platform. The first step is to add a new platform constant to
boost/process/config.hpp to identify the new platform. Once this is done, you will need to modify lots of source files to add support for it, including those in the library code, in the examples and in the test suite. Files that depend on a platform typically have the following conditional at the very beginning:
#include <boost/process/config.hpp> #if defined(BOOST_POSIX_API) // Inclusion of POSIX-specific headers. #elif defined(BOOST_WINDOWS_API) // Inclusion of Windows-specific headers. #else # error "Unsupported platform." #endif // Inclusion of portable headers.
It is important to note that only the first conditional in a given file carries the preprocessor error to ensure that the file is not compilable on an unsupported platform. Similarly the conditionals list all known platforms explicitly to denote that they were taken into account when writing or porting the code.