aboutsummaryrefslogtreecommitdiffhomepage
path: root/site
diff options
context:
space:
mode:
authorGravatar mtklein <mtklein@chromium.org>2015-02-05 10:58:48 -0800
committerGravatar Commit bot <commit-bot@chromium.org>2015-02-05 10:58:48 -0800
commit2fdd29d6e53d3c550bce711363a1d0d5b8069ee3 (patch)
tree7cfbb4396e84506a83d17adf8606cb3af177c87b /site
parent797f58a5297ccdc9226e716cbb69f9b8c5328ac9 (diff)
Document my current understanding of C++11 in Skia.
Diffstat (limited to 'site')
-rw-r--r--site/dev/contrib/c++11.md70
1 files changed, 70 insertions, 0 deletions
diff --git a/site/dev/contrib/c++11.md b/site/dev/contrib/c++11.md
new file mode 100644
index 0000000000..fb04a0d652
--- /dev/null
+++ b/site/dev/contrib/c++11.md
@@ -0,0 +1,70 @@
+C++11 in Skia
+=============
+
+Skia is exploring the use of C++11. As a library, we are technically limited
+by what our clients support and what our build bots support.
+
+Skia may also be limited by restrictions we choose put on ourselves. This
+document is not concerned with C++11 policy in Skia, only its technical
+feasibility. This is about what we can use, a superset of what we may use.
+
+The gist:
+ - C++11 the language as supported by GCC 4.4 or later is probably usable.
+ - If you break a bot, that feature is not usable.
+ - The C++11 standard library can't generally be used.
+ - Local statics are not thread safe.
+
+
+Clients
+-------
+
+The clients we pay most attention to are Chrome, Android, Mozilla, and a few
+internal Google projects.
+
+Chrome builds with a recent Clang on Mac and Linux and with a recent MSVC on
+Windows. These toolchains are new enough to not be the weak link to use any
+C++11 language feature. But Chrome still supports Mac OS X 10.6, which does
+not ship with a C++11 standard library. So [Chrome has banned the use of the
+C++11 standard library](http://chromium-cpp.appspot.com/). Some header-only
+features are probably technically fine, but the Mac toolchain will prevent us
+from even trying at compile time as long as we target 10.6 as our minimum API
+level.
+
+Chrome intentionally disables thread-safe initialization of static variables,
+and MSVC doesn't support it at all, so we cannot rely on that.
+
+Android builds with either a recent GCC or a recent Clang. They're generally
+not a weak link for C++11 language features. Android's C++ standard library
+has always been a pain, but since we can't use it anyway (see Chrome), don't
+worry about it.
+
+Mozilla's current weak link is a minimum requirement of GCC 4.6. Most features
+marked in red on Mozilla's C++11 [feature
+matrix](https://developer.mozilla.org/en-US/docs/Using_CXX_in_Mozilla_code) are
+marked that way because they arrived in GCC 4.7 or GCC 4.8. Their
+minimum-supported Clang and MSVC toolchains are great. They also appear to ban
+the C++ standard library.
+
+Internal Google projects tend to support C++11 completely, including the
+full C++11 standard library.
+
+
+Bots
+----
+
+Most of our bots are pretty up-to-date: the Windows bots use MSVC 2013, the Mac
+bots a recent Clang, and the Linux bots GCC 4.8 or a recent Clang. Our Android
+bots use a recent toolchain from Android (see above), and our Chrome bots use
+Chrome's toolchains (see above). I'm not exactly sure what our Chrome OS bots
+are using, but they've never been a problem.
+
+A few miscellaneous compile-only bots are actually our current overall weak link:
+ - Our NaCl builds use an old non-PNaCl toolchain, which is based on GCC
+ 4.4. GCC 4.4 has some support for C++11, but it's not nearly complete.
+ There is no upgrade path except PNaCl; even the very latest NaCl toolchain
+ is GCC 4.4, while PNaCl is based on Clang 3.4 (with complete C++11 support).
+ - Our iOS builds are driven from a Mac 10.7 machine using some unknown old Clang.
+ Who knows how old that is or what it supports? It's probably due for an update.
+
+If we were to eliminate the problems of the NaCl and iOS bots, our ability to
+use C++11 would match Mozilla's list nearly identically.