On Fri, Aug 2, 2013 at 1:36 AM, Joshua Cranmer 🐧 <pidgeo...@gmail.com>wrote:
> On 8/1/2013 5:46 PM, Brian Smith wrote: > >> FWIW, I talked about this issue with a group of ~10 Mozillians here in >> Berlin and all of them (AFAICT) were in favor of requiring that the latest >> versions of GCC be used, or even dropping GCC support completely in favor >> of clang, if it means that we can use more C++ language features and if it >> means we can avoid wasting time writing polyfills. Nobody saw installing a >> new version of GCC as part of the build environment as being a significant >> impediment. >> > > And how many of them have actually tried to install new versions of gcc > from scratch? As someone who works in compiler development, I can tell you > firsthand that setting up working toolchains is an intricate dance of > getting several tools to work together--the libc headers, the standard C++ > library headers, debugger, linker, and compiler are all maintained by > different projects, and a version mismatch between any two of these can > foul up getting things to work that requires a lot of time and patience to > fix even by people who know what they're doing. Look, for example, at some > of the struggles we have had to go through to get Clang-on-Linux working on > the buildbots. > We have mozilla-build for Windows. From what you say, it sounds like we should have mozilla-build for Linux too that would include a pre-built GCC or Clang or whatever we choose as *the* toolchain for desktop Linux. > Also, the limiting factor in using new C++ features right now is b2g, > which builds with g++-4.4. If we fixed that, the minimum version per this > policy would be g++-4.7. the limiting factor would either be STLport (which > is much slower to adopt C++11 functionality than other libraries tied > primarily to one compiler) or MSVC, which has yet to implement several > C++11 features. > Moving to GCC 4.7 is one of the requirements for the B2G system security project so I hope that happens soon anyway. Also, the set of code that is compiled for B2G is different (though, obviously overlapping) with the set of code that is compiled for desktop. In fact, if my understand of bug 854389 is correct, we could ALREADY be building Gecko with GCC 4.7 on B2G if we did one of two things: (1) Add a one-line patch to some Android header file, or (2) compile gonk with GCC 4.4 and compile Gecko with GCC 4.7 (or clang). If we have any more delays in upgrading to Jelly Bean then we should consider one or both of these options. > Instead of arguing right now about whether or not the minimum version > policy suggested by glandium and I is too conservative, perhaps we should > wait until someone proposes a feature whose need for polyfilling would > depend on that policy comes up. That sounds reasonable to me. So, based on that then, let's get back to my original question that motivated the discussion of the policy: If we add std::move, std::forward, and std::unique_ptr to STLPort for Android and B2G, can we start using std::move, std::forward, and std::unique_ptr throughout Gecko? Cheers, Brian _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
