On Wed, Jul 31, 2013 at 8:09 PM, Joshua Cranmer 🐧 <pidgeo...@gmail.com>wrote:
> > More generally, nobody should be reasonably expected to write code that >> builds with any combination that isn't used on mozilla-central's TBPL. So, >> (clang, MSVC) is not really something to consider, for example. >> > > clang + MSVC is not a combination I expect us to support anytime soon. My > main intent was to point out that library polyfilling is much harder than > it is for compiler features. Look at the mess that is determining when we > can use <atomic>. I agree with you. That is exactly why I suggested using the latest versions of every compiler whenever possible, and otherwise reducing the number of compiler+library combinations we need to deal with. > > functionality. The only time we should be requiring less than the latest >> version of any compiler on any platform is when that compiler is the >> compiler used for official builds on that platform and the latest version >> doesn't work well enough. >> > > I disagree. My baseline recommendation is that we should support the > newest compiler present on a stable distribution (I assume Debian stable > for a given ESR. This amounts to gcc 4.7 in practice on Linux at the > moment. Windows and OS X compiler support is harder to gauge, but I think > we should at least support the last two released versions of a compiler at > any given time. Clang releases roughly every 6 months and MSVC is moving to > a roughly yearly release schedule. This means that we should generally > expect to support any compiler version released in the last two or three > years. I am fine with you and Mike and others disagreeing with me. But, it is frustrating that you are saying that we should/must do these things, without providing any explanation of the reasoning behind your suggestions. Please explain why you are suggesting these things. > I think we need a single polyfill for C++ standard library features. NSPR > was that for C and POSIX, but as we get increasingly powerful things in > standard C++, it makes less sense to be using it for base platform support > (asynchronous I/O and sockets are planned for a networking TS). I've been > assuming that this C++ polyfill is MFBT, but it may make sense to separate > the C++ polyfill (+ arguably some stuff like Assertions.h/Attributes.h) > from the "assorted other ADT stuff" (like BloomFilter, SplayTree). > That sounds reasonable to me. But, I'd rather us upgrade compiler requirements than have us write any new polyfills for MFBT that would be unnecessary in the face of upgraded compiler requirements. Then the great developers that are often writing this code for MFBT could be writing great code to do something else. That isn't to say that we need to convert everything that currently uses MFBT things to use standard library things, if we think that the MFBT equivalent is substantially better than what the standard library offers. Cheers, Brian _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
