On 2015-03-11 8:36 PM, Gregory Szorc wrote:
On Wed, Mar 11, 2015 at 2:30 PM, Ehsan Akhgari <ehsan.akhg...@gmail.com <mailto:ehsan.akhg...@gmail.com>> wrote:On 2015-03-11 2:13 PM, Gregory Szorc wrote: On Wed, Mar 11, 2015 at 10:21 AM, Ehsan Akhgari <ehsan.akhg...@gmail.com <mailto:ehsan.akhg...@gmail.com> <mailto:ehsan.akhgari@gmail.__com <mailto:ehsan.akhg...@gmail.com>>> wrote: On 2015-03-11 7:35 AM, Brian Smith wrote: Mike Hommey <m...@glandium.org <mailto:m...@glandium.org> <mailto:m...@glandium.org <mailto:m...@glandium.org>>> wrote: Brian Smith wrote: It is very inconvenient to have a minimum supported compiler version that we cannot even do test builds with using tryserver. Why this sudden requirement when our *current* minimum "supported" version is 4.6 and 4.6 is nowhere close to that on try. That is also true for older requirements we had for gcc. That is also true for clang on OSX, and that was also true for the short period we had MSVC 2012 as a minimum on Windows. I'm not saying this is an ideal situation, but I'd like to understand why gcc needs to suddenly be treated differently. The current situation is very inconvenient. To improve it, all compilers should be treated the same: Code that builds on mozilla-inbound/central/__tryserver is good enough to land, as far as supported compiler versions are concerned. So, for example, if clang 3.7 is what is used on the builders, then clang 3.6 would be unsupported. And the same with GCC and MSVC. In my ideal world, instead of spending time debating what compilers we should use, we would stop relying on the system compiler, and build on all platforms with known good compilers of our choosing. That of course requires some build system work to get the compilers installed etc and unfortunately I don't think we have anyone lined up to do that work. But if we ever got there, we could have total control over what compilers are used to build our code, so we would not be affected by external factors such as distros' compiler choice. I would prefer the default build mode construct a chroot or Docker environment [that is the same environment Mozilla uses in automation] and we build in that. This build environment would be defined inside mozilla-central in such a way that it is reproducible over time. e.g. update your source repo to a commit from March 2015 and you automatically get the build environment that was used in March 2015. Another aspect of this switch is it gets us much closer to deterministic and reproducible builds. Docker will be a Linux specific solution though, right? Are there similar plans for other platforms In terms of system parity, Linux is the most difficult. Every distro is different. Windows and OS X are more uniform. We get much more consistency and predictability on these platforms, especially Windows, where MozillaBuild is essentially a self-contained build environment (albeit with the OS-level isolation that Docker or LXC provides). I'm pretty sure we deal with more system incompatibilities issues from build system land with Linux than we do OS X and Windows combined. Supporting a well-defined and isolated build environment for Windows and Mac is more difficult. We even have licensing issues complicating matters. We do pretty well on both fronts today, even without the "strong" isolation provided by Docker/LXC. Without Docker, I think we'd be fine with continued use of MozillaBuild and something like a Mozilla-specific Homebrew/MacPorts install or something.
Hmm, why not do something much simpler then, which is downloading a prebuilt zip file that contains the toolchain? The toolchains on Mac and Linux are redistributable, and for Windows we can redistribute a little python script that creates the toolchain from a Visual Studio Commmunity Edition installation.
_______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
