Re: std::unique_ptr, std::move,
On Thu, Aug 1, 2013 at 7:46 PM, Mike Hommey m...@glandium.org wrote: On Thu, Aug 01, 2013 at 04:25:25PM -0700, Matt Brubeck wrote: Debian doesn't keep Iceweasel up to date in oldstable anyway. Actually, I'm providing backports for oldstable. 24 is as far as I'm ready to go to support oldstable until its actual EOL next year. Which is why i want ESR24 to remain compilable with gcc 4.4. Upgrading minimum compiler requirements doesn't imply backporting those requirements to Aurora where ESR24 is right now. Are you opposed to updating our minimum supported gcc to 4.7 on trunk when Firefox OS is ready to switch? Cheers, -- Ehsan http://ehsanakhgari.org/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: std::unique_ptr, std::move,
On Fri, Aug 02, 2013 at 08:27:02AM -0400, Ehsan Akhgari wrote: On Thu, Aug 1, 2013 at 7:46 PM, Mike Hommey m...@glandium.org wrote: On Thu, Aug 01, 2013 at 04:25:25PM -0700, Matt Brubeck wrote: Debian doesn't keep Iceweasel up to date in oldstable anyway. Actually, I'm providing backports for oldstable. 24 is as far as I'm ready to go to support oldstable until its actual EOL next year. Which is why i want ESR24 to remain compilable with gcc 4.4. Upgrading minimum compiler requirements doesn't imply backporting those requirements to Aurora where ESR24 is right now. Are you opposed to updating our minimum supported gcc to 4.7 on trunk when Firefox OS is ready to switch? Not at all, as long as ESR24 keeps building with gcc 4.4. I've even been complaining about b2g still using gcc 4.4 on trunk... Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: std::unique_ptr, std::move,
On Fri, Aug 2, 2013 at 2:58 PM, Mike Hommey m...@glandium.org wrote: Upgrading minimum compiler requirements doesn't imply backporting those requirements to Aurora where ESR24 is right now. Are you opposed to updating our minimum supported gcc to 4.7 on trunk when Firefox OS is ready to switch? Not at all, as long as ESR24 keeps building with gcc 4.4. I've even been complaining about b2g still using gcc 4.4 on trunk... This adds too much risk of security patches failing to backport from mozilla-central to ESR 24. Remember that one of the design goals of ESR is to minimize the amount of effort we put into it so that ESR doesn't slow down real Firefox. AFAICT, most people don't even want ESR at all. So, a constraint to keep ESR 24 compatible with GCC needs to include some resources for doing the backports. Cheers, Real Brian ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: std::unique_ptr, std::move,
On Fri, Aug 2, 2013 at 1:36 AM, Joshua Cranmer pidgeo...@gmail.comwrote: 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
Re: std::unique_ptr, std::move,
On 2013-08-02 4:49 PM, Brian Smith wrote: 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? Yes, if they're available in all of our environments, I don't see why not. What we want to be careful with is how the STLport changes would work (we don't want to make builds fail if you just grab an Android NDK). Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: std::unique_ptr, std::move,
On 2013-08-02 4:39 PM, Brian Smith wrote: On Fri, Aug 2, 2013 at 2:58 PM, Mike Hommey m...@glandium.org mailto:m...@glandium.org wrote: Upgrading minimum compiler requirements doesn't imply backporting those requirements to Aurora where ESR24 is right now. Are you opposed to updating our minimum supported gcc to 4.7 on trunk when Firefox OS is ready to switch? Not at all, as long as ESR24 keeps building with gcc 4.4. I've even been complaining about b2g still using gcc 4.4 on trunk... This adds too much risk of security patches failing to backport from mozilla-central to ESR 24. Remember that one of the design goals of ESR is to minimize the amount of effort we put into it so that ESR doesn't slow down real Firefox. AFAICT, most people don't even want ESR at all. So, a constraint to keep ESR 24 compatible with GCC needs to include some resources for doing the backports. How does this add too much risk? Patches that we backport to ESR are usually fairly small, and there is already some risk involved as the codebases diverge, of course. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: std::unique_ptr, std::move,
Brian Smith wrote: 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. mozilla-build doesn't include a compiler or SDK. At one point we supported three (six if you include x64) compilers and three SDKs (except I don't think one of the compilers supported one of the SDKs, but that wasn't mozilla-build's fault). -- Warning: May contain traces of nuts. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: std::unique_ptr, std::move,
On Sat, Aug 3, 2013 at 12:51 AM, Ehsan Akhgari ehsan.akhg...@gmail.comwrote: This adds too much risk of security patches failing to backport from mozilla-central to ESR 24. Remember that one of the design goals of ESR is to minimize the amount of effort we put into it so that ESR doesn't slow down real Firefox. AFAICT, most people don't even want ESR at all. So, a constraint to keep ESR 24 compatible with GCC needs to include some resources for doing the backports. How does this add too much risk? Patches that we backport to ESR are usually fairly small, and there is already some risk involved as the codebases diverge, of course. There are two kinds of risks: The risk that any developer would need to waste time on ESR just to support a product that isn't even Firefox on a platform that virtually nobody uses, and the risk that comes with making any changes to the security fix that you are trying to backport. The ideal case (assuming we can't just kill ESR) is that your backport consists of hg graft and hg push and you're done. That is what we should optimize for, as far as supporting ESR is concerned. You are right, of course, that ESR and mozilla-central diverge as mozilla-central is improved and there are likely to be merge conflicts. But, we should not contribute to that divergence unnecessarily. How many developers are even insisting on building Firefox on a Linux distro that insists on using GCC 4.4, who are unwilling to upgrade their compiler? We're talking about a very, very small minority of people, AFAICT. I know one of those people is Mike, who is a very, very important Mozillian who I definitely do not intend any insult. But, it really does seem to me that instead of us trying to bending to the desires of the most conservative distros, the rational decision is to ask those distros who insist on using very old tools for very long periods of time to solve the problem that they've caused themselves with their choices. I think we could could still feel really good about how Linux-friendly we are even if we shifted more of these kinds of burdens onto the distros. Again, no offense intended for Mike or any other maintainer of any Linux distro. I have nothing against Debian or any group. Cheers, Brian -- Mozilla Networking/Crypto/Security (Necko/NSS/PSM) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: std::unique_ptr, std::move,
On 8/2/13 8:14 PM, Brian Smith wrote: The risk that any developer would need to waste time on ESR just to support a product that isn't even Firefox on a platform that virtually nobody uses, and the risk that comes with making any changes to the security fix that you are trying to backport. I feel that there's an important piece of data missing here: how many patches get backported to ESR in practice? -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: std::unique_ptr, std::move,
On Sat, Aug 3, 2013 at 12:50 AM, Ehsan Akhgari ehsan.akhg...@gmail.comwrote: On 2013-08-02 4:49 PM, Brian Smith wrote: 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? Yes, if they're available in all of our environments, I don't see why not. What we want to be careful with is how the STLport changes would work (we don't want to make builds fail if you just grab an Android NDK). I am not quite sure what you mean. Here is the workflow that I was envisioning for solving this problem: 1. Add std::move, std::forward, and std::unique_ptr to STLPort (backporting them from STLPort's git master, with as few changes as possible). 2. Write a patch that changes something in Gecko to use std::move, std::forward, and std::unique_ptr. 3. Push that patch to try (try: -b o -p all -u all -t none). 4. If all the builds build, and all the tests pass, then ask for review. 5. After r+, land on mozilla-inbound. If all the builds build, and all the tests pass, then anybody/everybody is free to use std::move, std::forward, and std::unique_ptr. To me, this is the most (only?) reasonable way to decide when enough configurations support a language feature/library we are considering using. Cheers, Brian Ehsan -- Mozilla Networking/Crypto/Security (Necko/NSS/PSM) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: std::unique_ptr, std::move,
On Sat, Aug 03, 2013 at 02:14:10AM +0200, Brian Smith wrote: On Sat, Aug 3, 2013 at 12:51 AM, Ehsan Akhgari ehsan.akhg...@gmail.comwrote: This adds too much risk of security patches failing to backport from mozilla-central to ESR 24. Remember that one of the design goals of ESR is to minimize the amount of effort we put into it so that ESR doesn't slow down real Firefox. AFAICT, most people don't even want ESR at all. So, a constraint to keep ESR 24 compatible with GCC needs to include some resources for doing the backports. How does this add too much risk? Patches that we backport to ESR are usually fairly small, and there is already some risk involved as the codebases diverge, of course. There are two kinds of risks: The risk that any developer would need to waste time on ESR just to support a product that isn't even Firefox on a platform that virtually nobody uses, and the risk that comes with making any changes to the security fix that you are trying to backport. The ideal case (assuming we can't just kill ESR) is that your backport consists of hg graft and hg push and you're done. That is what we should optimize for, as far as supporting ESR is concerned. You are right, of course, that ESR and mozilla-central diverge as mozilla-central is improved and there are likely to be merge conflicts. But, we should not contribute to that divergence unnecessarily. All the refactoring we're doing is already making these divergences more significant than supporting an older toolchain does. You can't just hg graft and hg push over changes such as the s/PRBool/bool/ type changes (and we're going to do a lot of them over the lifetime of ESR24). I doubt we'd want to backport these refactorings to ESR. So while i feel for your concern, it just hasn't much to do with the toolchain problem. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: std::unique_ptr, std::move,
On 07/31/2013 01:25 AM, Brian Smith wrote: Anyway, it would be easier to swallow the dependency on MFBT if it wasn't so large (over 100 files now), if it tried to be (just) a polyfill for missing standard library features, and if it could easily be used independently of the Gecko build system. But, none of those constraints is reasonable to place on MFBT, so that means MFBT isn't a good choice for most things that need to also be able to be built independently of Gecko. I disagree about independently-usable being an unreasonable constraint -- it seems totally reasonable for it to be a mini-embeddable thing, or something. But making it exactly that, without some of the hacks we have now for things like header-installation, etc., requires 1) time, 2) build-fu, and 3) understanding of the requirements of small little embeddable things, and I lack all these. On 07/31/2013 03:34 AM, Mike Hommey wrote: I am of the opinion that anything that is not a header file under MFBT should be moved into mozglue. The end result would be the same (MFBT is actually built into mozglue, except for js standalone builds, for which this would require some changes), but it would allow MFBT to just be used independently. Truly I don't care about the naming, but I've always envisioned mfbt as being headers and some compiled-into-objects files both, i.e. as the union of what you consider mfbt, and the compiled-in bits of it. Is there a good reason to have mozglue and what you consider mfbt to be two different things? Why not have both as a single thing, and make the whole thing more easily embeddable if necessary? Jeff ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: std::unique_ptr, std::move,
On Wed, Jul 31, 2013 at 2:19 PM, Mike Hommey m...@glandium.org wrote: On Wed, Jul 31, 2013 at 01:06:27PM +0200, Brian Smith wrote: On Wed, Jul 31, 2013 at 12:34 PM, Mike Hommey m...@glandium.org wrote: I strongly oppose to any requirement that would make ESR+2 (ESR31) not build on the current Debian stable (gcc 4.7) and make ESR+1 (ESR24) not build on the old Debian stable (gcc 4.4). We're not going to change the requirements for the latter. And b2g still requires gcc 4.4 (with c++11) support anyways. Until they switch to the same toolchain as android, which is 4.7. Why are you so opposed? I feel like I can give a lot of good reasons why such constraints are a net loss for us, but I am not sure what is driving the imposition of such constraints on us. Because Mozilla is not the only entity that builds and distributes Gecko-derived products, including Firefox, and that we can't demand everyone to be using the latest shiny compiler. You are not answering the question. You are just making your assertion in a different way. First of all, when we created ESR, there was the understanding that ESR-related concerns would not hold back the mainline development. Any discussion about ESR in the context of what we use for *mozilla-central* is going against our original agreements for ESR. 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. Everybody using Windows or Windows as their development environment has to download and install a multitude of programs and libraries in order to build Gecko. I've never heard of a justification for why Linux needs to be different. And, in fact, except for the compiler/linker/etc., Linux isn't different; that's why we have bootstrap.py that downloads and installs a bunch of stuff for Linux too. Why should only the compiler (including linker, etc.) only on Linux be treated specially? What justifies the reduced productivity that results from us wasting time writing unnecessary polyfills and/or writing worse code to avoid language features that aren't supported on some particular Linux distribution's version of GCC? How many developers working on Firefox are even using Debian as their development platform? What percentage of Firefox users are using Firefox on Debian? My position is that we should be doing everything we can to improve developer productivity, and that means using the best possible tools we have available to us. I have a hard time seeing how any Linux distributions' policies could possibly be more important than our productivity. Cheers, Brian ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: std::unique_ptr, std::move,
On Wed, Jul 31, 2013 at 8:09 PM, Joshua Cranmer pidgeo...@gmail.comwrote: 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
Re: std::unique_ptr, std::move,
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. 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. 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. -- Joshua Cranmer Thunderbird and DXR developer Source code archæologist ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: std::unique_ptr, std::move,
On Thu, Aug 01, 2013 at 04:25:25PM -0700, Matt Brubeck wrote: Debian doesn't keep Iceweasel up to date in oldstable anyway. Actually, I'm providing backports for oldstable. 24 is as far as I'm ready to go to support oldstable until its actual EOL next year. Which is why i want ESR24 to remain compilable with gcc 4.4. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: std::unique_ptr, std::move,
On Wed, Jul 31, 2013 at 6:53 AM, Joshua Cranmer pidgeo...@gmail.comwrote: On 7/30/2013 10:39 PM, Brian Smith wrote: Yes: Then we can use std::unique_ptr in parts of Gecko that are intended to be buildable without MFBT (see below). One thing I want to point out is that, while compiler features are relatively easy to select based on catching macro versions, the C++ standard library is not, since compiler versions don't necessarily correlate with standard library versions. We basically support 4 standard libraries (MSVC, libstdc++, stlport, and libc++); under the right conditions, clang could be using any of those four versions. This means it's hard to tell when #include'ing a standard header will give us the feature or not. The C++ committee is actively working on a consensus solution to this issue, but it would not be rolled out to production compilers until 2014 at the earliest. Basically, I'm proposing that we add std::unique_ptr, std::move, std::forward, and some nulllptr polyfill to STLPort with the intention that we can assume these features work. That is, if some (compiler, standard library) combination doesn't have these features then it would be an unsupported combination. 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. One of the goals of MFBT is to bridge over the varying support of C++11/C++14 in current compilers, although it also includes useful data structures that are not necessary for C++ compatibility. Since we have an increasing number of semi-autonomous C++ projects in mozilla-central, it makes sense that we should have a smallish (header-only, if possible?) compatibility bridge library, but if that is not MFBT, then I don't know what it is or should be. As it stands, we have a fair amount of duplication right now. We should be more aggressive in requiring newer compiler versions whenever practical, and we should choose to support as few compiler/library combinations as we can get away with. That way we can use as many C++11/14 features (not just library features, but also language features) as possible without any portability shims, and we can save developer effort by avoiding adding code to MFBT that duplicates standard library 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. Anyway, it would be easier to swallow the dependency on MFBT if it wasn't so large (over 100 files now), if it tried to be (just) a polyfill for missing standard library features, and if it could easily be used independently of the Gecko build system. But, none of those constraints is reasonable to place on MFBT, so that means MFBT isn't a good choice for most things that need to also be able to be built independently of Gecko. Cheers, Brian ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: std::unique_ptr, std::move,
On Wed, Jul 31, 2013 at 10:25:15AM +0200, Brian Smith wrote: We should be more aggressive in requiring newer compiler versions whenever practical, and we should choose to support as few compiler/library combinations as we can get away with. That way we can use as many C++11/14 features (not just library features, but also language features) as possible without any portability shims, and we can save developer effort by avoiding adding code to MFBT that duplicates standard library 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 strongly oppose to any requirement that would make ESR+2 (ESR31) not build on the current Debian stable (gcc 4.7) and make ESR+1 (ESR24) not build on the old Debian stable (gcc 4.4). We're not going to change the requirements for the latter. And b2g still requires gcc 4.4 (with c++11) support anyways. Until they switch to the same toolchain as android, which is 4.7. Anyway, it would be easier to swallow the dependency on MFBT if it wasn't so large (over 100 files now), if it tried to be (just) a polyfill for missing standard library features, and if it could easily be used independently of the Gecko build system. But, none of those constraints is reasonable to place on MFBT, so that means MFBT isn't a good choice for most things that need to also be able to be built independently of Gecko. I am of the opinion that anything that is not a header file under MFBT should be moved into mozglue. The end result would be the same (MFBT is actually built into mozglue, except for js standalone builds, for which this would require some changes), but it would allow MFBT to just be used independently. Note that I've been picking a few MFBT headers without any problem to build the android linker independently. Albeit, it's not cross platform. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: std::unique_ptr, std::move,
On Wed, Jul 31, 2013 at 12:34 PM, Mike Hommey m...@glandium.org wrote: I strongly oppose to any requirement that would make ESR+2 (ESR31) not build on the current Debian stable (gcc 4.7) and make ESR+1 (ESR24) not build on the old Debian stable (gcc 4.4). We're not going to change the requirements for the latter. And b2g still requires gcc 4.4 (with c++11) support anyways. Until they switch to the same toolchain as android, which is 4.7. Why are you so opposed? I feel like I can give a lot of good reasons why such constraints are a net loss for us, but I am not sure what is driving the imposition of such constraints on us. Cheers, Brian -- Mozilla Networking/Crypto/Security (Necko/NSS/PSM) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: std::unique_ptr, std::move,
On Wed, Jul 31, 2013 at 01:06:27PM +0200, Brian Smith wrote: On Wed, Jul 31, 2013 at 12:34 PM, Mike Hommey m...@glandium.org wrote: I strongly oppose to any requirement that would make ESR+2 (ESR31) not build on the current Debian stable (gcc 4.7) and make ESR+1 (ESR24) not build on the old Debian stable (gcc 4.4). We're not going to change the requirements for the latter. And b2g still requires gcc 4.4 (with c++11) support anyways. Until they switch to the same toolchain as android, which is 4.7. Why are you so opposed? I feel like I can give a lot of good reasons why such constraints are a net loss for us, but I am not sure what is driving the imposition of such constraints on us. Because Mozilla is not the only entity that builds and distributes Gecko-derived products, including Firefox, and that we can't demand everyone to be using the latest shiny compiler. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: std::unique_ptr, std::move, and std::forward (was Re: Using C++0x auto)
On Tue, Jul 30, 2013 at 7:40 PM, Brian Smith br...@briansmith.org wrote: On Fri, Jul 19, 2013 at 4:46 AM, Mike Hommey m...@glandium.org wrote: Note that STL is another story. We're not using libstdc++ that comes with the compiler on android and b2g. We use STLport instead, and STLport has, afaik, no support for C++11 STL types. So, while we can now fix nsAutoPtr to use move semantics instead of copy semantics, we can't use std::unique_ptr. I saw bug 896100 [1] wants to add mozilla::Move and mozilla::Forward. Obviously, that is a clear improvement that we can build on. Agreed. But, shouldn't we just name these std::move and std::forward and use these implementations only when we're using STLPort? I know we're not supposed to add stuff to the std:: namespace normally, but that's exactly what STLPort is doing. We've avoided doing this so far in MFBT for everything in the language or the standard library that we had to reimplement ourselves. I'm not aware of any practical problems in putting things in the std namespace (besides watching out for name clashes, which most standard library implementations avoid by either using nested namespaces for their implementation helpers, or symbols with underscore at the beginning of their name which are supposed to be reserved for implementations -- but real code in the while violates that all the time.) But it still feels a bit unclean to put things into namespace std. Is there a good reason why we should do that in this case? (Also remember that STLport is an STL implementation, so it is entirely ok for them to put things into namespace std!) And, more to the point, shouldn't we just add std::unique_ptr to STLPort for Android so we can use std::unique_ptr everywhere? And/or just backport the libstdc++ version to GCC 4.4. Isn't it all just templates? I believe that std::unique_ptr can be implemented in C++ without any compiler magics, and this sounds like a good idea (but I still think we should call ours mozilla::UniquePtr.) Cheers, -- Ehsan http://ehsanakhgari.org/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: std::unique_ptr, std::move, and std::forward (was Re: Using C++0x auto)
On Tue, Jul 30, 2013 at 10:50:39PM -0400, Ehsan Akhgari wrote: On Tue, Jul 30, 2013 at 7:40 PM, Brian Smith br...@briansmith.org wrote: On Fri, Jul 19, 2013 at 4:46 AM, Mike Hommey m...@glandium.org wrote: Note that STL is another story. We're not using libstdc++ that comes with the compiler on android and b2g. We use STLport instead, and STLport has, afaik, no support for C++11 STL types. So, while we can now fix nsAutoPtr to use move semantics instead of copy semantics, we can't use std::unique_ptr. I saw bug 896100 [1] wants to add mozilla::Move and mozilla::Forward. Obviously, that is a clear improvement that we can build on. Agreed. But, shouldn't we just name these std::move and std::forward and use these implementations only when we're using STLPort? I know we're not supposed to add stuff to the std:: namespace normally, but that's exactly what STLPort is doing. We've avoided doing this so far in MFBT for everything in the language or the standard library that we had to reimplement ourselves. I'm not aware of any practical problems in putting things in the std namespace (besides watching out for name clashes, which most standard library implementations avoid by either using nested namespaces for their implementation helpers, or symbols with underscore at the beginning of their name which are supposed to be reserved for implementations -- but real code in the while violates that all the time.) But it still feels a bit unclean to put things into namespace std. Is there a good reason why we should do that in this case? (Also remember that STLport is an STL implementation, so it is entirely ok for them to put things into namespace std!) Note that if STLport is the only thing preventing us from using some C++11 std:: features, we can implement them and contribute them upstream. That being said, it does look like the STLport git has unique_ptr, forward and move. It's not part of any release, though, and I'm not sure how good the current trunk is. The version we're currently using is 5.2.1 + some Android patches (pristine from the android NDK) Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: std::unique_ptr, std::move, and std::forward (was Re: Using C++0x auto)
On Wed, Jul 31, 2013 at 4:50 AM, Ehsan Akhgari ehsan.akhg...@gmail.comwrote: On Tue, Jul 30, 2013 at 7:40 PM, Brian Smith br...@briansmith.orgwrote: But, shouldn't we just name these std::move and std::forward and use these implementations only when we're using STLPort? I know we're not supposed to add stuff to the std:: namespace normally, but that's exactly what STLPort is doing. We've avoided doing this so far in MFBT for everything in the language or the standard library that we had to reimplement ourselves. I'm not aware of any practical problems in putting things in the std namespace (besides watching out for name clashes, which most standard library implementations avoid by either using nested namespaces for their implementation helpers, or symbols with underscore at the beginning of their name which are supposed to be reserved for implementations -- but real code in the while violates that all the time.) But it still feels a bit unclean to put things into namespace std. Is there a good reason why we should do that in this case? Yes: Then we can use std::unique_ptr in parts of Gecko that are intended to be buildable without MFBT (see below). (Also remember that STLport is an STL implementation, so it is entirely ok for them to put things into namespace std!) To be clear, I am not proposing that we add std::move/forward/unique_ptr to MFBT. I am suggesting that we add them to STLPort. We could even eventually upstream them. EDIT: I just saw Mike's post that STLPort upstream already has unique_ptr/move/forward. Perhaps we can backport them into our STLPort tree. FWIW, we have created a new certificate verification library written in C++. One of my goals is to eventually make it so that it can be embedded in server-side software to support things like OCSP stapling, short-lived certificates, and auto-fixing of certificate chains in servers, which are things that make SSL faster and easier to deploy. Basically, the idea is that the server can (pre-)build/verify their certificate chain exactly as Firefox would. There are also some security researchers interested in using a real browser's certificate processing logic in studies they are doing. This kind of research directly benefits my work on Gecko and I'm intending to share this library with them so they can use it in their research. For this sub-project, I've been trying to avoid any Gecko (including MFBT) dependencies and I will be cutting down (removing?) the NSPR and NSS dependencies over time. In order to avoid the MFBT dependency, I created my own ScopedPtr class and cviecco added a hack for GCC 4.4's nullptr. We also have been doing the typical hacky/dangerous stuff to deal with a world without std::move()/forward() and without cstdint. Now we can use cstdint (or at least stdint.h?), and I'm eager to fix these last mile issues. Besides that, in general I'd like to continue making Gecko's code less foreign to C++ coders. In particular, I'd like to get rid of nsAutoPtrT and mozilla::ScopedPtrT completely. Cheers, Brian ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: std::unique_ptr, std::move,
On 7/30/2013 10:39 PM, Brian Smith wrote: On Wed, Jul 31, 2013 at 4:50 AM, Ehsan Akhgari ehsan.akhg...@gmail.comwrote: On Tue, Jul 30, 2013 at 7:40 PM, Brian Smith br...@briansmith.orgwrote: But, shouldn't we just name these std::move and std::forward and use these implementations only when we're using STLPort? I know we're not supposed to add stuff to the std:: namespace normally, but that's exactly what STLPort is doing. We've avoided doing this so far in MFBT for everything in the language or the standard library that we had to reimplement ourselves. I'm not aware of any practical problems in putting things in the std namespace (besides watching out for name clashes, which most standard library implementations avoid by either using nested namespaces for their implementation helpers, or symbols with underscore at the beginning of their name which are supposed to be reserved for implementations -- but real code in the while violates that all the time.) But it still feels a bit unclean to put things into namespace std. Is there a good reason why we should do that in this case? Yes: Then we can use std::unique_ptr in parts of Gecko that are intended to be buildable without MFBT (see below). One thing I want to point out is that, while compiler features are relatively easy to select based on catching macro versions, the C++ standard library is not, since compiler versions don't necessarily correlate with standard library versions. We basically support 4 standard libraries (MSVC, libstdc++, stlport, and libc++); under the right conditions, clang could be using any of those four versions. This means it's hard to tell when #include'ing a standard header will give us the feature or not. The C++ committee is actively working on a consensus solution to this issue, but it would not be rolled out to production compilers until 2014 at the earliest. For this sub-project, I've been trying to avoid any Gecko (including MFBT) dependencies and I will be cutting down (removing?) the NSPR and NSS dependencies over time. In order to avoid the MFBT dependency, I created my own ScopedPtr class and cviecco added a hack for GCC 4.4's nullptr. We also have been doing the typical hacky/dangerous stuff to deal with a world without std::move()/forward() and without cstdint. Now we can use cstdint (or at least stdint.h?), and I'm eager to fix these last mile issues. One of the goals of MFBT is to bridge over the varying support of C++11/C++14 in current compilers, although it also includes useful data structures that are not necessary for C++ compatibility. Since we have an increasing number of semi-autonomous C++ projects in mozilla-central, it makes sense that we should have a smallish (header-only, if possible?) compatibility bridge library, but if that is not MFBT, then I don't know what it is or should be. As it stands, we have a fair amount of duplication right now. Besides that, in general I'd like to continue making Gecko's code less foreign to C++ coders. In particular, I'd like to get rid of nsAutoPtrT and mozilla::ScopedPtrT completely. I'm actually planning on discussing this in more detail in a newsgroup post I'm working on right now. -- Joshua Cranmer Thunderbird and DXR developer Source code archæologist ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
