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:
execve(2)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.
CreateProcesswhich receives all the configuration parameters for the new child. The documentation avoids referring to these operating systems as Windows because there are other implementations that follow the Win32 API out there (e.g. Wine or ReactOS).
Important: From now on the documentation will refer to the POSIX and Win32 platforms, not specific operating systems. When specifying a platform name, the text refers to its process management model and supported features not present in the other models; it is not referring to any particular operating system.
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_PROCESS_POSIX_API|
|NetBSD 3.x and 4.x||POSIX||BOOST_PROCESS_POSIX_API|
The third column in the table above mentions the name of a preprocessor constant
defined by the
header 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 be 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|
||GCC 3.3 and 4.0 as shipped with XCode 2.3|
||GCC 3.x and 4.x|
||Microsoft Visual Studio 2005|
This list might not be exhaustive as concerns the library code, but when trying a new toolset, the test suite will not pass cleanly unless some minor changes are made to it. Again, please tell us if you make Boost.Process work with any other toolset so that it can be added to the list.
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 Win32 systems.
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 issues 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
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
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_PROCESS_POSIX_API) // Inclusion of POSIX-specific headers. #elif defined(BOOST_PROCESS_WIN32_API) // Inclusion of Win32-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.
|Copyright © 2006 Julio M. Merino Vidal|