I'd like to follow up on this old thread to discuss what we can do about improving the mingw developer experience for people doing Windows-centric stuff.
I've had several patches backed out over the past month because of mingw header files differing in case from the headers distributed by the official Windows SDK. Frankly, it's a waste of developer time to be dealing with this. This is particularly frustrating in the case of autoland, where we can't just push our own follow-up patches. Those of us who are trying to do Windows-specific stuff are effectively stuck simultaneously coding to two similar, yet still different, SDKs, being built across two distinct operating systems that differ in case sensitivity. In some cases, discrepancies between the SDKs are inevitable: Perhaps mingw hasn't kept up with the official Windows SDK and some headers/APIs are missing. We just have to take those as they come. But when it comes to the header case mismatch issue, we could automate this. Would it be possible for us to write some code to automatically detect these case discrepancies and automatically land corrections? Where would be the right place for something like that to live? Those of us locally building on Windows already have enough annoyances with the build as-is, so I don't consider "you should be building locally on both Windows/MSVC and Linux/mingw simultaneously" to be a reasonable option. Nor do I consider always pushing mingw jobs to try to be ideal: it delays the landing of patches and potentially wastes build machine time, compared to an automated lint. Furthermore, can we clarify whether mingw is currently a tier 1 or tier 2 platform? Earlier in this thread, mingw was denoted as tier 2 (and it still shows up as tier 2 on treeherder), yet sheriffs are backing out patches when mingw bustage occurs. Tor is important, so of course we want to make our best effort to ensure that mingw isn't broken, but this "tier 2 but really tier 1" state is not helpful. I apologize for being curt, but this is becoming rather frustrating. Aaron On Mon, Oct 9, 2017 at 10:14 AM, Tom Ritter <t...@mozilla.com> wrote: > On Mon, Oct 9, 2017 at 10:31 AM, Philipp Wagner <n...@philipp-wagner.com> > wrote: > > > Am 09.10.2017 um 07:31 schrieb Tom Ritter: > > > As part of our work with Tor, we’ve been working on getting a > MinGW-based > > > build of Windows into TaskCluster. > > > > A maybe too obvious question from the side lines: Why is the Tor browser > > cross-compiled and not using MSVC? > > > > > Building on Linux allows Tor Browser (including its entire toolchain and > dependencies) to be built deterministically and thus reproducibly using an > entirely open source toolchain. (There are a few small exceptions but > they're quite small.) > > Reproducible builds significantly reduce the trust inherent in an > organization's build infrastructure and when recreated independently ensure > that nothing unexpected was inserted into the final executable. Having the > entire toolchain open source ensures that anyone who wants to inspect the > code or reason about its behavior can do so. (And as I've learned in the > past year Tor actually has a good amount of anonymous contributors reading > the source code of its toolchain and reporting things.) > > You can read more about the philosophy behind this movement at > https://blog.torproject.org/deterministic-builds-part-one- > cyberwar-and-global-compromise > https://reproducible-builds.org/ > CCleaner is a good example of attackers backdooring compiled software. > > The next step, past reproducible builds, is Binary Transparency, which > ensures that before an update is applied, it is publicly known, so > attackers cannot surreptitiously subvert the update mechanism. Tor is > exploring some avenues there. FLAME is a good example of attacking the > update mechanism. > > I would describe Mozilla as 'curious' about reproducible builds (see > https://bugzilla.mozilla.org/show_bug.cgi?id=885777); but we are actively > working on Binary Transparency (see > https://bugzilla.mozilla.org/show_bug.cgi?id=1341395). > > -tom > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
