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
