Hi there,
I'm currently in the process of porting the Boost libraries to a new
platform called CloudABI. CloudABI is a POSIX-like runtime environment
that is purely built on the concept of capability-based security. In a
nutshell, it means that actions that have side-effects outside of a
process can only be performed if the process owns a capability (a file
descriptor). In other words, open() is missing, but openat() is still
there. There are only local filesystem namespaces.
CloudABI allows you to reduce the impact of security exploits through
sandboxing, but also makes it possible to safely run untrusted
third-party applications without requiring any virtualization,
containers, etc. Be sure to check out the GitHub page for more
details:
https://github.com/NuxiNL/cloudlibc
The other day I started experimenting with getting Boost working on
CloudABI and I noticed that most of the Boost sources already build on
CloudABI. I somewhat expected this, because Boost sources tend to be
written in a loosely coupled, testable way. But still, hats off to the
Boost developers! The biggest showstopper -- as expected -- is
boost::filesystem, which will likely never work on CloudABI:
https://groups.google.com/a/isocpp.org/forum/#!msg/std-proposals/q1F0KDEBtfg...
But in many cases there are also classes that can optionally access
the filesystem through utility functions (boost::locale::gnu_gettext,
boost::program_options::parse_config_file(), etc).
The reason why I'm sending this email is because I want to propose
adding a new configuration option,
BOOST_NO_GLOBAL_FILESYSTEM_NAMESPACE, that I can use to conditionally
disable such utility functions. I've attached a patch for Boost.Config
to this email.
Does this approach seem reasonable? Do we like the name of this build
option? Does the patch look all right? It seems as if generate.cpp
also made some unnecessary changes to these files. What's up with
that?
Best regards,
--
Ed Schouten